Consider These 3 Misconceptions to Eliminate Destructive Behaviors in Your Agile Management
The point of the agile framework is to allow teams to accomplish smaller, more manageable pieces of work, get client feedback, quickly adapt and correct issues. There are many benefits of this methodology but, like many other management approaches, the problem is in the details – how do you determine what those smaller pieces of work are and how do you find the best way to move forward after receiving feedback?
In this article we present few common misconceptions of agile product development:
1. Taking the MVP approach to its extreme
MVP (Minimal Viable Product) approach is sometimes misinterpreted as “the least we can do” to produce functional item. This concept may be valuable in some cases where you’re building non-core features that need to ‘check the box’, it is completely improper when launching a major product or feature.
When implementing an MVP approach the issue that is decayed is the ‘Viable’ piece. The viable means that at worst, some of your clients would use this feature as created, even if it’s very limited in scope; that it is the essence of the agile method and is aligned with its core – providing a great user experience, for example.
Some organizations use MVP as a way to test client and business reactions to new products and features, but what differentiates the world’s top tech companies from the rest on the market is that their MVPs are not partial or poorly designed. Software companies constantly release 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 valid for both their great successes (Google Search, Gmail) and failures (such as Google Wave).
If you apply MVP approach to its essence, focusing only on ‘minimal’ and neglecting ‘viable’, your approach could result in poorly executed products that get very little traction, fail to delight clients and create a culture of mediocracy.
2. Being too quick to interpret errors and failures
When you launch a new feature, an experiment or a real MVP, and go out to get user and client’s feedback. Sometimes the results will be much worse than expected: conversions are lower than your baseline, users do not adopt the new functionality, etc. So, what should you do next? Should you abandon the MVP approach? Maybe you didn’t identify the market need, or was it a failure to design the right solution for the need?
People often have the difficulty to interpret and take action based on market feedback, because they failed in defining the questions they set to be answered in the first place. If you don’t know the exact questions you should answer and how many resources you’re willing to invest to uncover them, it’s no surprise that you may be unsure how to act once the results are in.
On a high level, there are 2 different types of questions. The first is – ‘should we build this feature?’, and the second is a qualitative one – ’Is this feature good enough?’ or, ‘How can we make this better?’ Each type of question needs different skills set to be answered and, more importantly, has a different set of criteria to determine success or failure.
The basic error that product teams do very often in that context – is interpret mediocre or bad results from a product or feature launch, as proof of lack of market knowledge (answering the “should we…?” question), rather than as an indication that the solution was not well designed or implemented (the good enough question).
No organization will survive if it interprets every tactical failure as a sign its core business is improper. Apparently, there comes a time where multiple tactical failures may indicate a more strategic problem and the need to leave a product or feature idea, but the bar for that type of action is much higher.
3. Not balancing Agile with persistence
For team leaders, the risk of taking Agile approaches to the extreme is that features and products they release are partial, do not deliver enough value or provide a poor customer experience, leading to negative market feedback followed by a premature decision to quit.
If you’re applying an MVP you should ask yourself some simple questions – does it bring value? Are you fine with its quality and usability? If you’re unpleased by it, but convince yourself that ‘yes, it’s bad, but we’ll release it as is and learn’ – don’t go ahead with it, the MVP is not suitable for you.
You should ensure that you know the questions you should answer by releasing an MVP and estimate how long you’re willing to go at it before you report failure and quit. Admitting that you’re ‘trying out a new UX design this week’ is ok, but you should add “we will monitor its performance and iterate to improve it over the next quarter”.
If you want to benefit from Agile’s methodology you should be balanced by adding the persistence and strategic thinking that would allow you to evaluate your progress in the spirit of your long term goals.
