A universal challenge for technology companies is having more demands to improve the product than we can implement. This problem gets bigger as we get more successful.
Because our capabilities and those demands shift over time — if we want to maximize the value of what we deliver to the customer, then we want to tackle things in a prioritized fashion, knowing we simply won’t get to it all in any one release cycle.
And this prioritized breakdown better supports moving to a lean/ kanban workflow.
How to best analyze and prioritize all these requests, then? We want to be able to do it systematically, regularly, and have these priorities reflect (the best we can) the sweet spot of both the market value of an idea, and the engineering cost to create it1.
This last part is difficult, but especially important.
Say we have a few alternative design ideas for satisfying a need. Because it may appear “anything is possible” in software, we may be tempted to try to deliver exactly “what the customer wants.” Let’s say that’s design A. Unfortunately, developing design A could be a bad choice, because it could easily take many times the effort of a very similar and nearly as appealing choice B, just because it asks for some functionality that doesn’t neatly fit into our existing system and available components around us. A fundamental principle of software engineering is that even a small shift in requirements can cause a huge shift in cost and/or risk of development.
It’s similar to choosing to fit within the limitations of available off-the-shelf parts for a home remodel — it is obviously much cheaper than buying custom.
But “off the shelf” is an unfortunately non-obvious, slippery concept in the shifting world of software. To reuse something, whether it’s your own code or someone else’s, there’s often a chain of “if”s you have to walk down: “We can save 2 months of effort by using this nice library IF we assume customers want Windows .NET only; IF we use C#; IF we take a dependency on .NET Framework 3.5 SP1 to get the libraries we need; IF we only do features A, B, D, and E, and punt on C, because it would require we rewrite and replace the library…” and every such path is usually followed by a “BUT, if we do that, then we are locked into not doing …”.
In most cases, developers on your projects won’t know all the alternatives and consequences until they’ve delved deeply into the design and usually into the code.
This is one of many reasons why two strategies are so important in getting (re)prioritization right for software engineering:
- Include both marketing and engineering equally in the decisions of what features to prioritize. Systemically account for both world views, while coming to one decision.
- Plan to adjust your feature set over the course of the project, as your team learns new things. By allowing for small adjustments and sacrifices in the requirements, you can dramatically lower the project cost and risk.
#2 is common advice for a host of reasons. #1 can be achieved with the right people, and a structured decision making method like perpetual multivoting, or a Delphi decision making method that will be described in a future post.
When the right people are paired with the right process in this way, the spigot of innovation will open wider, benefiting both you and your customers.
(1) We actually want the sweet spot of the triumverate of Voice of the Customer (VOC), Voice of Technology (VOT), and Voice of the Business (VOB) — so we can prioritze the work that will deliver the most value to our customer, with the lowest effort and risk, with the best financial outcome for our company. In many companies, we break these perspecives down (for better or worse) into specializations: sales represents the pure VOC, marketing VOB, and engineering VOT. So the challenge is — finding a sweet spot means getting perspectives from several people, often with very different backgrounds and communication styles, who wouldn’t normally be caught dead getting drinks at the same pub with each other …