No agile practices or processes are substitutes for a Roadmap or Vision
More and more I see Products/Start-ups failing to sell once they go out to the market. Here’s my take on their main reason of failure.
Problem: The Product Manager has an Idea for a Product and starts throwing User Stories to the Team. The Team consumes them using the discipline they have devised by themselves thought the Sprints. Because we are doing Agile and Usability Studies, everything just have to end up fine, right? So at the end of the engineering effort the website will progressively go from glugging some sales to enabling more servers to control the fire hose throwing sale requests. Reality? if your are managing your product as I just described your are playing at the jackpot. You will have chances to have a fire hose throwing sales, but those chances are the same as hitting the jackpot.
Listen! Synthesize!
A Product Manager has to have conviction of his/her vision and the understanding that detractors will try to take the Product down, I mean, we live in the human jungle, don’t we? However, such a conviction has to be tempered with Company’s Business Strategy, market trends, with Subject Matter Experts opinions, and, most important, with fact your Product is changing the world for better, that you are solving a real pain. So listening has to be the key factor when envisioning a Product. After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.
The Mirage of Bad Assumptions in Review Meetings and Usability Studies
A Review meeting becomes obsolete if you don’t have a Subject Matter Expert to evaluate the Sprint results. If you are doing software for kids, guess what, the final acceptance word is for the kids to give, not for you. When I say Acceptance Word, I mean: From a Product stand point, we got a increment, which is apart from the achievement the team has accomplished. If the team delivers what you asked for but displeased your final user, congratulate genuinely the team achievement and blame your inability of transmitting what the user needed to be solved. Although is vital to have team members skilled in the Product domain, I strongly recommend not to have a SME inside the team. Paying consulting hours to a external SME disconnect him/her from the fear of trying to please the Product Owner. The SME doesn’t have to fear telling the Product Manager “Your baby is ugly” or “Your baby is cute but the bodysuit that is wearing today is horrible”.
On the other hand, Usability Tests are tricky. First of all, Usability Studies are not a substitution of Marketing Studies. The latter are inputs for the former. Why? Because as Usability Test Facilitator will always be able to find users that fit a wrong characterization of your persona. The persona can easily represent a market segment that is not big enough to make your product profitable.
Let’s dot the i’s and cross the t’s
Scrum and popular Agile practices are good to deliver complex products on time assuring Product Owner satisfaction and fulfilling his/her vision. But Scrum and popular Agile practices don’t cover all the responsibilities of a Product Manager, even more, the Product Owner role is a subset of responsibilities of a Product Manager. The ScrumMaster needs to receive a vision from the Product Owner to transmit it to the team. The Product Manager articulates a continuously validated vision and Product Strategy and then articulate a continuously validated Product Backlog. Don’t forget build an Agile Release Plan with clear milestones.
Further reading:
- It’s always about the problem
- Market problems are still THE problem — even when you’re Agile! (Excellent post of my friend
Luke Hohmann) - Retooling Early Stage Development
No comments yet.