Like in a game of Broken Telephone, some of the most common terms used to describe agility and the “new age” of startup culture and product development have taken a meaning quite different than their original intent, one that could be counter productive and in some cases destructive to teams’ ability to execute.
The essence of agile methodology is allowing teams to handle smaller, more manageable chunks of work, get market feedback, quickly adapt and correct course. The benefits of this approach are numerous but, like many other management approaches, the devil is in the details – how do you determine what those smaller chunks of work are and how do you find the best way to move forward after receiving feedback?
Here are a few common misconceptions of agile product development:
Minimal Viable Product is often misinterpreted as ‘the least we can do to deliver functionality’. Although this interpretation may be valuable in some cases where you’re building non-core features that need to ‘check the box’, it is completely unsuitable when launching a major product or feature.
What is often neglected when implementing an MVP approach is the “Viable” piece. To me, viable means that at least some of your customers would use this feature as launched, even if it’s very limited in scope; that it is accretive to your product and is aligned with its DNA – providing a great user experience, for example.
Many companies use MVP as a way to test consumer and business reactions to new products and features, but what differentiates the world’s top tech companies from the rest of the pack is that their MVPs are not half baked or poorly designed. Google constantly releases Beta products and Labs features that are very limited in scope yet deliver the experience and the core value they’d like to test as part of an MVP – this is true for both their great successes (Search, Gmail) and failures (remember Google Wave and other Google failures?).
Taking the MVP approach to its extreme, focusing solely on “Minimal” and neglecting “Viable”, is a destructive approach that results in poorly executed products that get very little traction, fail to delight customers and create a culture of mediocracy.
So you launched a new feature, an experiment or a real MVP and set out to get user and customer feedback. Unfortunately the results are much worse than expected: conversions are lower than your baseline, users do not adopt the new functionality, etc. Where do you go from here? Should you kill this feature or iterate? Did you fail to identify the market need or was it a failure to design the right solution for the need?
What I see quite often is that the difficulty to interpret and take action based on market feedback stems from not defining the questions you set out to answer in the first place. If you’re not sure what the questions you’re trying to answer are and how much resources you’re willing to invest to uncover them, it’s no surprise that you may be unclear how to act once the results are in.
At a high level, there are two very different types of questions. The first is a binary one — Should we build this product? — while the second is essentially a qualitative one — Is this good enough? or, How can we make this better? Each type of question requires a different set of tools to answer and, more importantly, has a different set of criteria to determine success or failure.
The most common mistake I see product teams do in that context is interpret mediocre or bad results from a product or feature launch as proof of lack of market need (answering the Should we… question) rather than as an indication that the solution was not well designed or implemented (the good enough question).
No startup would survive if it interprets every tactical failure as a sign its core business is flawed. Obviously, there comes a time where multiple tactical failures may indicate a more strategic problem and the need to abandon a product or feature idea, but the bar for that type of pivot is much higher.
Balancing Agile with Persistence
For product leaders, the risk with taking Agile approaches to the extreme is that features and products you release are half baked, do not deliver enough value or provide a poor customer experience, leading to negative market feedback followed by a premature decision to quit.
When building an MVP ask yourself a few simple questions – does it add value? are you comfortable with its quality and usability? If you’re embarrassed by it but convince yourself that “yeah, it’s bad, but we’ll release it as is and learn” – don’t go ahead with it, this is not your MVP.
Make sure you know exactly what are the questions you’d like to answer by releasing an MVP and estimate how long you’re willing to go at it before you declare failure and quit. Saying “we’re trying out a new UX design this week” is ok, but you should add “and will monitor its performance and iterate to improve it over the next quarter”.
To benefit from Agile’s many benefits it needs to be balanced by adding the persistence and strategic thinking that would allow you to evaluate your progress in light of your long term goals