Being responsible for envisioning and shaping the end user experience is one of the most rewarding responsibilities in building digital products. One of the hardest decisions a product manager will make is determining when something is "done."
Determining when to “be done enough” is often a negotiation. The negotiation typically converges around some kind of contract. In agency situations, this is often a tangible document that all parties agree on at the onset of the engagement. These inked "Statements of Work" aside; we also make nominal “micro contracts” with our collaborators and stakeholders everyday as the product evolves.
Micro contracts are established continuously through the conversations we have, concepts we express visually, and in writing as we learn and course-correct throughout the product development process.
These micro contracts frequently become the living expectation benchmark for the project, despite the precedence of a written contract; and despite the fact that these dynamic, micro contracts are typically undocumented.
What’s interesting about this characterization is not how static and dynamic contracts function - both are expressions of consensus - but rather that the two will often coexist in a single project, each illustrating divergent paths. Two different expressions of intent: One Project.
How can a written contract mandate one thing while micro contracts tell us another on the same project? Which one is the arbiter of “done enough”?
Therein lies the negotiation.
We cannot know all that we need to know to plot a course to the optimal outcome at the start of a project. We can only use the information that is reasonably obtainable to make the best decisions possible.
It is a near certainty that even the best possible plan on Day 1 will not remain the “right plan” for long.
Making the right thing will often take us down a different path than the one we assumed at the start. Micro commitments are always more realistic than a requirements-heavy contract that is agreed to at the start of a project, in good faith but without full knowledge of what lies ahead.
The static, written contract may quickly become inaccurate and obsolete, particularly in Agile product development environments where earning trust, good collaboration and communication are of greater importance. In fluid environments like the one we have here at MojoTech, these tenets perform a similar function as a contract would in a hypothetical static situation.
Another important distinction to consider is that product development doesn't have a discrete finish line. It isn’t like advertising or paid media in that regard. There is no grand unveil or half-time show. It doesn’t run N times and then go into archive. Product development is continuous, and therefore we must adopt practices, measures and expressions that are designed for continuous development and are accepting of change. No finish lines; just stopping points.
The Iron Triangle
As a project or team lead, you’re responsible for managing expectations and for delivering results. Successfully negotiating a stopping point depends largely on these two things.
If you ship products at an organization worth its salt then you’re familiar with the “iron triangle”: the relationship between cost, schedule and scope. This project management concept is the framework through which all product decisions should be passed whether you’re building tools internally or at a consultancy.
These are the levers we must keep in balance, and the key measures by which we monitor the project throughout its development. Keeping schedule, scope and cost in balance is an essential skill if you’re to be successful in managing expectations and delivering results.
If your project plan does not take into account the relationship between scope, schedule and cost, then it is not a plan at all. As an entrepreneur or product owner, a desired outcome without a plan is really just a hope and a dream...
In a business environment, the iron triangle is a valuable tool for guiding our decision-making because it helps us to express the trade-offs of a given decision and discern “value." When your intent is to productize and monetize a tool, there is simply no such thing as a zero-schedule or zero-cost scenario – conditions that describe a hobby project.
Amongst many responsibilities to our client partners at MojoTech, one is to ensure that the team understands the trade-offs of the decisions we must make, as well as the underpinning "why" that informs our approach to the problem.
In practice, there can be tension between maintaining Agile Product Development practices and honoring the "big vision".
Even projects with exceptional communication, trust and collaborative synergy can experience turbulence as a stopping point comes into sight. After weeks or months of course correcting from initial assumptions and establishing thoughtful micro contracts along the way, the static contract is resurfaced, heralding the original “big vision” for the product.
Sometimes the assertion that we "do less" may sound like we're saying, "let's choose the lesser quality option." This way of thinking is to equate "less" with being "worse", when the measure we ought to be weighing is "value."
Value is a measure of benefit and cost.
In finding optimum value we face the quintessential Agile directive: "Let's build this smaller working increment first because we agree that it makes the experience better than what we have today, will be immediately serviceable, and it will allow us to move onto the next set of essential features outstanding. We can come back to it when it has become the next most important thing to enhance."
There will always be "more" to do.
To make a given feature (or product) more full-featured, more automated or more hassle-free is to simply do more. Building more requires more man hours, which means more time.
In a given iteration, reaching for "just a bit more" can seem benign. This can be true. In the aggregate however, all of those small concessions can add up, and that can mean more cost and more risk.
It is a slippery slope because a product or experience is never "finished" - remember, no finish lines - yet we often feel compelled to do more right now [to honor the “big vision”]. We must ask, "Do users need this right away? Do we know they want it? Is it worth spending time building?"
This way of thinking is at the root of Agile and Lean methodologies and is what fundamentally separates itself from monolithic, requirements-driven product development.
In a monolithic "waterfall" approach, a large (often single) vision is specified and the team drives forward until that end result is met. This is a traditional way of thinking and building software.
This approach is undesirable for several reasons. Here are a few:
1.) Speed to market. You are withholding value from your customers every day you don't launch. The product owner/client gets no yield from the undertaking until the vision is realized completely. And because the big vision is always larger than the sum of its parts, it takes longer to realize it completely.
2.) Cost. When you commit yourself to a monolithic build plan you have accepted all of the risk (cost) that lies between its starting point and its end. Neither you or the development team can know all unknowns at the onset. And in an iron triangle scenario, if more effort is required to deliver the big vision, other potentially important features are put at risk of not getting built as time and/or budget is spent.
3.) Building the wrong thing. When you commit to a monolithic build plan, the feature (or product) is often unusable until the time and money is already spent. When you ship small and ship often you can involve customer feedback in the development of your product or experience. When you do this you invariably build something they want to use because they are telling you explicitly what they want.
There is far more risk in assuming what users will need than it is to build something small, let users try it and tell you what enhancements they want from it.
This practice of learning, assessing, then iterating from "the nominal plan to the right plan" is another quality that defines Agile.
Many times you will learn that a feature you were keen to build out further is not worth enhancing at all; users just don't care enough about it. At that point, you will be happy that you exercised restraint in not "building more" eagerly so you can now spend your resources on the features that you know are important.
The great paradox is that we feel compelled to build more features from a place of risk mitigation.
We want to ensure at the onset that our users will have everything they'll need, but in doing so we often put far more at risk.
-Andrew
Disagree with Andrew publicly on Twitter @Sheddybird or in stealth mode like Christian Slater and John Travolta in "Broken Arrow" at andrew@mojotech.com