Conceptually, building a product might seem like a rather simple set of activities - gather requirements internally and/or externally, write user stories, work with engineering to build the darn thing and release to the customers. I often hear of the analogy of product management to co-ordinating work between disparate teams. This is such a big misnomer as building impactful product experiences is a balance of scientific art, strategic and tactical mindset that is peppered with just the right soft skills that make an awesome product manager. At Spark To Substance, we have found over the years that the top 5 superpowers of great product managers look like the following:
For any CEO or Product Leader looking to elevate product thinking and these superpowers in their product team, contact us for our unique coaching and training services.
Early on in my career, I had struggled with the above perception of product management even though it was rather comforting to believe in it initially as it highly simplified the high stake decisions and work of a product manager. 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 and years later I understood the danger to that thinking.
I followed this process very early on in my career and mistook software delivery as product management. I often felt like I did not belong and there was a disconnect in what was being expected of me and what I naturally felt I needed to do. Fortunately I had invested in a product coach very early in my career and he had helped me see the flaws in the above mindset and opened my mind to the magic of building products.
If you are thinking about investing in your product management career, talk to us today!
Unpacking Innovation Challenge with a Design Sprint
How did one of my teams in a eCommerce company I worked for challenge the delivery mindset status quo? We reframed the business challenge of acquiring more users and attempted to solve this using Google Venture's Design Sprint framework. However, frameworks are mere frameworks if not applied appropriately for the context of the problem at hand. We were extremely proud that we followed the book to the T and attempted all the following key steps:
Map the business challenge
Prioritize on the right part of the journey to focus
Identify assumptions to validate
Sketch possible solution ideas
Prototype
Validate & Test with Customers
We followed a full 5 day sprint framework and tested our prototype with our users. However we learnt that what we prototyped was not at all what our users needed. In many scenarios this would have been acceptable if innovation sprints were business as usual ways to declutter ideas and focus on the right problems. However, for us, this was the company's first attempt to try something as radical as bringing a handful of cross functional team members together for 5 full days.
We made several mistakes along the way and our experience emphasized crucial misses that teams often take it for granted:
No frameworks are bullet proof. They need to be thoroughly understood and then applied
We decided to facilitate the design sprint ourselves and this prevented an objective and unbiased facilitation. We were too close to the problem and our favorite solution ideas
We did not prioritize our assumptions and hence went in to prototype our ideal solution
We used design sprint on the solution versus the problem. We made a fundamental mistake in assuming our solution was what our users needed. We forgot to validate the problem
What Did We Learn
The objective of design sprints, any other innovation framework or experimentation is to accelerate learning in the team. Moreover, if the learning demonstrates that the original hypothesis was flawed, then it is not strategic to build it anyway just because that hypothesis was something the team was trying to learn from. We do hear about how teams need to build everything that is on the backlog and what we saw above is a fundamental shift to "Build everything trap" or a "Feature Factory Mindset". It is not about output, rather outcomeIt 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 Service Sprint etc may not always help achieve outcomes.
Don’t get me wrong – I am a huge believer of problem 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.
If you are ready to kick start innovating in your business, we like you to rethink if bringing on an external facilitator might be a good fit for you. Let Spark To Substance be your innovation partner with empathy!