Reframing Product Versions
Moving teams from output- to outcome-focused requires a step change in understanding and internally publicizing what product versions mean
“The biggest lie in software is Phase 2.” — Lean UX by Jeff Gothelf and Josh Seiden
Version 2 is now live! Have you ever heard of customers talking about Version 2 of a new software? Most likely not. They will, however, talk about new features and functionality that help them achieve something they couldn’t do in the past or that opens up new services to them.
Sustainable product growth comes from continuing to provide value to both new and existing customers. There is still some benefit to publicizing new versions of software — to help secure the next round of VC funding, for example. But there’s something much more impressive than simply stating a new version is being started: communicating the number of customers using the product and returning to it on a regular basis.
By now, most organizations, big or small, believe in iterative design and Agile development practices, with varying degrees of success. Most will agree that “big-bang” software releases are risky and potentially damaging. They’re daunting for the team to launch, can be jarring for existing customers, are unproved with new customers, and pile on the pressure for the business and product teams to “get it right first time.” Even with the amount of research and testing some of the best Agile teams do, every significant release of versioned software is at risk of completely failing.
Agile and Lean principles help us minimize that risk by exhorting that we practice ongoing customer feedback loops, shorter release cycles, and iterative design and development. While there are now many organizations adhering to these practices, there’s still a tendency to hold back on large sets of features to release them as a “Version 2” after an MVP stage.
How can we reframe what a “version” is, so existing customers are retained, new customers find value sooner, and VCs are confident the product or service is going in the right direction for them to invest?
If you happen to be in one of those organizations that is able to evolve a product over time without any mention of versioning, then go ahead and skip this article. Instead, maybe take a look at hypothesis-driven design or this framework to help validate new product features.
What’s in a version?
Generally, new software versions can be put into three categories:
- Releasing one large feature or a set of new features
- An entire visual user interface overhaul in line with a new brand direction
- A complete infrastructure or architecture rebuild using new technology
The latter two are nearly always combined with the first, as teams can’t justify the development or big upfront design cost with no customer-facing functional output to satisfy business stakeholders. This makes it incredibly difficult to iterate on visual design or architecture as a lone initiative. It’s also impossible to align any of this work with product goals, as there’s no discernible end-customer outcome to measure.
Equally true is that, while there may be a need for a technical or visual overhaul, most teams will not be advertising these to end-customers, whether new or existing. There’s just no value to them knowing this work has been completed or why it was needed. Both should have residual effects, from a quality or brand recognition point of view, on users, who are already finding ongoing value in product functionality.
There’s also the complete redirection of product vision to consider. What is learned from an MVP is enough to pivot entirely, due to a lack of product–market fit. Some might call this a second version, but in reality, the team is starting again, with more understanding of the market, and experimenting with a new MVP.
Thinking big and executing small
Recently, I was speaking with a product manager who was about to release a Version 2 of their mobile app. The new version was a mixture of the three categories above. They’d moved to React Native as a framework and replaced tired cartoonish visuals and tone of voice with something more aligned to the clinical support they provide. Finally, they’d decided to replace a core set of functionality completely.
They were worried about the release, and rightly so. Even though they’d done their upfront work, customer research and usability testing, and they’d kept Agile processes to a level they were comfortable with, there were still huge outstanding questions with how their existing user base might react to the changes.
They had little idea about how the new visual aesthetic would go down, how the tone of voice might resonate with customers, or crucially, if the new functionality would be an acceptable replacement for something that was already being heavily used. This work was underpinned by new technology that, though it had been thoroughly tested, could potentially produce issues when out in the wild.
This might be fine for potential new customers, if the research is thorough, but as mentioned above, sustainable product growth comes from gaining new customers and retaining existing ones. Releasing this second version could cause serious confusion, leading to anxiety in the existing user base, especially considering the domain: clinical health support.
Releasing this as a Version 2 sounds great for getting crucial VC funding. The team can tell the story of what they spent their money on previously and where the next lot of money will go. It’s also important with B2B services or SaaS, where contracts are signed on the promise of building future functionality.
What about the end-users of this service? Could this new version of the software be released in much smaller chunks, thereby minimizing risk with existing customers? Could releasing smaller and more often mean new customers see value sooner? Can this be done while continuing to convince both VCs and B2B customers that the direction of the product is sound?
Front-loading product promises
Based on the number of feature deliverables set by the business, the number of people the team has, and the time and tools available to complete the work, it’s very simple to state what the next product version will consist of.
This isn’t great product management, and it can lead to a damaging state of apathy, where teams are only interested in what needs to be released for a version, rather that the impact their work has on customer outcomes.
What will most likely happen here is either not everything will get done, some features will go to the next version, or the current deadline will be pushed back; or everything gets done, and more features are pulled in. That’s the problem with estimation — it’s mostly pointless guesswork that provides structure where none is needed.
On the face of it, the latter sounds great — more features in this version! But it sets a deliverable precedent that is damaging to teams and, eventually, the quality of the product itself. Quality always drops, either from a design and usability or technology perspective, when the expectation of a team to deliver in a given time frame exponentially increases.
The problem here is that new versions are promised at the very beginning, when no work has even started and where teams are building features based solely on research and prototype usability testing. They really have no idea what impact the new features will have in the wild, and most likely, they’ll never get chance to find out, as they move into the next phase of delivery.
There is no going back from this; it’s a promise to the business. It’s a promise this work will be completed, regardless of what actual end-users think. It forces an often-arbitrary deadline on the team that helps neither team morale nor quality of work; both suffer when everything is rushed through with no looking back.
Make versions a success story, not a deliverable
There’s an alternative solution that adheres to Agile principles and Lean experimentation processes. Promise the business that certain customer outcomes will be met and make the version cut at the end, once all the new features and functionality changes have achieved the goal.
Reframing product versions as customer-outcome goals requires a shift in mindset that is driven by the need to achieve something the customer finds valuable and from which the business attains benefit, rather than blindly producing endless sets of features.
If the team can state that the latest version they released achieved key customer outcomes — achieved goals that align to the product strategy with a number of features that were iterated over time — it becomes a much more powerful and compelling message than simply stating a list of features to cram into a set time frame.
This makes new versions of the software a celebration of the team’s achievement. It provides existing customers with an evolving valuable experience, and new customers will see value sooner. VCs and B2B customers will be won over with achieved measures of success that align to business goals and revenue.
The team will now be measured not on the number of features they are to produce (outputs), but instead, on what customer value they’re aiming to achieve (outcomes).
Building evolutionary product, teams and terminology
The oft-cited Conway’s Law can be loosely applied here. Teams that talk about software versions with a set feature output, in a given time, are bound to produce software that reflects that: bloated, rushed, and lacking in both quality and customer value.
Eventually, the team will get to a place of total product experimentation and evolution. There will be no need for product versioning or similar language, and the business will trust the teams to deliver what is required to meet the outcomes they are setting.
This takes time. It’s not an overnight change to move from output- to outcome-focused teams or versions. The reframing of product versions here is just one step on the route to changing the mindset of teams and the businesses they work in to be more problem- and outcome-focused.