Use Agile to Bring Discipline Into Your Product Development Process


Let’s consider a scenario where the Decision Maker for a new product initiative has just said something like: “There’s no way I would ever sign off on this as anything other than a fixed price contract.” While the rationale behind such an approach is, well, rational, from a certain perspective, it threatens to miss the whole point of new product development.

This approach commonly arises in situations where the value proposition or business model for the product isn’t clear or the market is not well understood. Let’s unpack why this approach may be detrimental to your product in the long run.


Focus Shift - Is it about the opportunity, or the budget?

First off, fixed price means fixed scope. Some finite set of things will be delivered. To the greatest extent possible, these things should be known to a reasonable level of detail before a contract can be agreed upon. You see, in the cost first paradigm, the vendor is forced to view risk through the same lens. As both parties need to agree on the scope and the price, a planning process ensues wherein both are attempting to simultaneously define the product and manage their respective degrees of risk. This is like trying to do two opposing things at once but we’ll get to that later. Inevitably, subtly, the value proposition in the mind of the DM becomes rooted in how much product will be obtained for the dollars spent instead of focusing on what the product will be.


Priority Shift - It’s almost what we agreed to only different, possibly way different

In a new product scenario, working under a fixed contract is hard to do. At the beginning, you probably don’t know as much about the customer as you should. Your theories about the market and your value proposition and business model are untested. While it’s easy to conceive a bunch of cool stuff that may be relevant, what you potentially have are a bunch of opinions: interesting but not necessarily relevant.

No sooner than the ink is dry on the contract, keeping the product locked into it's original mold becomes a real challenge. The more of the product you start to see, the more insight you get into what you are really after. If you’re putting the product in front of early test subjects, it’s even worse because the onslaught of new insights comes even faster. Now what do you do?


Reality Shift - We thought it was cool, customers say it sucks

You’ve got this fixed price, fixed scope contract yet, clearly, the product has taken on a life of it’s own. From here on out, it just gets tougher and tougher to sort out what to keep, what to throw out, and what to add: not because of the product but because of the constraints of the CONTRACT! It’s hard to assess if the feature you rough estimated months ago and didn’t build is an even swap for the thing that everyone now agrees should be built instead. Wrangling the disparities between an outdated scope and what you now know the customer wants drains away time and attention that should be spent elsewhere.


Paradigm Shift - The thing that gets managed is the thing that gets the most attention

The blind spot of the fixed scope approach is that it’s doing just the opposite of what it was intended to do. The real risk that needs to be managed with new products is not cost it’s opportunity risk! If you have truly identified a great opportunity, what is the risk if you get the product wrong? A big ‘ol pile of wrong bought at an attractive price is a fail. The thought that a fixed price contract will save money is an illusion.

Remember the part about two opposing things at once? In the Agile model, this is resolved by separating the opposing forces and doing just one thing at a time. By prioritizing the product, all participants are able to focus on what the product needs to be successful. Managing risk then becomes an exercise in not building too far ahead in the product roadmap and disciplined prioritization based on real-world feedback.

A better approach is to lay out a high level roadmap, key product attributes, resources required and a rough time frame. Use these factors to build an ESTIMATE of development costs for budgeting purposes. After that, plan each sprint based on what are the highest value features you can build right now. As this is a pay as you go approach, real value gets assigned to every feature and items in the backlog compete with one another to make the cut. The feature prioritization process can get pretty ruthless but eventually you realize that there are no sacred cows and individual features become less precious. Only the best features survive in this environment!

Now the focus is on delighting customers and driving revenue, or adoption or whatever your key metric happens to be. When you look back over the twists and turns in your development cycle, you’ll likely find fewer features on the trash heap and fewer rounds of iteration on the ones that survived. Whether you save money or not, the end result will be a product wherein you've maximized the efficiency of your capital investment and stayed focused on producing the best product possible.