Right Product at a Right Time…
Conceptually, building a product may seem like a rather simple activity — gather requirements internally and externally, write user stories, work with development to build the darn thing and release. Merely using the tools, processes and frameworks that are the flavors of the day or the year seem to be the holy-grail to ship products.
Over the years, I have come to struggle with this sentiment even though I believed in it initially. I still remember someone showing me a graphical representation of a typical agile/scrum workflow years back suggesting that this was it — this is how we ship products. I followed the process very early on in my career when I abandoned the world of development for what I believed was product management. The image looked something like this, which I am sure a lot of us in are familiar with…
The emphasis to ship something, just something has become so much that we have begun to live in a feature factory. More than often it does not really depend how and if the features are being used by the users as long as we have something to demo and ship by the end of the sprint (if following Scrum) or have a release cadence with Kanban. Usage, first experiences, engagement, retention, active users are often after-the-fact metrics as long as team velocity is maintained.
How did my team at one of the companies I worked for challenge this status quo? We ran a 5-day Design Sprint and followed GV’s methodology to the book. Somewhere along the way after validating our prototype, something did not quite sit well — yes we validated the prototype with actual users albeit they were only 5 but lets face it — qualitative feedback will always most likely be fewer than quantitative feedback. Our team decided to run a simple poll that’s took less than 10 minutes to set up (no dev effort required). We received more than 3000 responses over the weekend in less than 2 days indicating that the pure demand for what we were hypothesizing did not exist at this time for the two personas impacted by this.
What does this show?
We could have spent months building to the prototype that was validated — hey we followed the entire Design Sprint process. We would have shipped multiple features to support our validated prototype but it would have been something that users either did not use and we would not have had any material impact.
This is where I truly believe my team achieved something bigger here by not building the above — product management is not just about shipping features and functionalities.
- It is not about output, rather outcome
- It is about building something that is relevant
This was a win by my standard for the team that I am super proud of. And this is exactly where simply following processes and tools like the Agile or Design Thinking or Design Sprint or JTBD may not always help achieve outcomes. Don’t get me wrong — I am a huge believer of these customer discovery tools and frameworks but at the same time I also believe that tools are only as good as it gets — one needs to adapt them to fit your context, stage of the product or in our case the user persona.