As product managers, it’s expected of us to immerse ourselves in our customers world, understand the problem they are trying to solve ....
As product managers, it’s expected of us to immerse ourselves in our customers world, understand the problem they are trying to solve, the industry they are trying to fix and the solution they propose to create. As it’s only then that we can develop meaningful products.
It’s also extremely important the Product Manager understands the vision for the product as we are responsible for clearly communicating that vision to everybody on the team such that they understand how they are contributing to it.
However, if like me, as a product manager in a fast moving environment it’s somewhat of an art to immerse yourself into your next project/ startup.
The advantage of being a PM in a product consultancy is I get to experience a wide variety of different startups, founders, industries, technologies, apps, websites, problems, solutions, you name it!
This might sound great, but it’s also a double edged sword.
For all these advantages I listed above, I need to quickly adapt to the next startup I get involved with and fast, and in doing so I need to do a lot of research, discussions with the founder, end user research, UX/UI workshops, competitor analysis research and the list goes on….
So since my time as a PM I‘ve had to develop an effective deep-dive system to rapidly immerse myself.
I call this system ‘Product Immersement’. And in case you are wondering, no ‘product immersement’ isn’t a phrase, at least I couldn’t find any record of it, so you heard it hear first folks! 🙌🏼
Lastly, this is not an exhaustive guide and will most definitely be tweaked as I progress through my Product Management career with further experience. This is a framework that should be applied in the way most relevant to your situation.
The best way to understand the client’s objectives is by reading their business plan. The business plan typically provides a clear and concise summary of the business idea and its objectives. This is a great way to get up to speed fast. The document should provide information regarding a description of the business/ product (executive summary section), market fit/share, competitive analysis etc.
We have adopted an approach called “working backwards” that is widely used at Amazon. According to Ian McAllister, General Manager at Amazon.
“We work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it.”
At ucreate we encourage our product managers to create an internal press release announcing the finished product, it is “centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions”, writes McAllister.
We then keep iterating on the press release until we’ve come up something concise and explains the end product well.
Facilitate a workshop with the client and their team including any stakeholders. At ucreate we typically hold three half day workshops and call this our exploration phase.
The first workshop largely consists of getting to know to each other better, discussing each persons roles and responsibilities within the project.
These subsequent workshops are spent analysing the business opportunity, establishing the main problems and challenging the clients assumptions. Together, we create a few elevator pitches and vision statements. We then establish the main problem worth solving and the overall goal of the business.
Make a list of the most important technologies related to your product and do intensive research to make sure you understand them. If there are engineers on your team who are experts in particular technologies, spend some time with them and have them educate you on the technology. Play on their desire to be the expert and you’ll find that they are more than willing to share their knowledge so that you can quickly get up to speed.
After our internal workshops, research and discussions we produce a product bible. This is typically the last step in the process as the document summarises all the findings from the previous steps, drawing all your research and workshop findings together in one comprehensive document.
This final step of writing the product bible really helps me align myself with the clients overall vision for the product as it’s where all the previous steps come together. It is also worth noting the product bible is not a fixed document and that it evolves as we validate, learn and iterate throughout the lifecycle of the product.
What do you think of this process? Do you have a particular technique? I would love to hear your thoughts.
