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. 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 so they understand how they are contributing to it.
However, as a Product Manager in a fast-moving environment, it’s somewhat of an art to immerse yourself into your next project/start-up.
The advantage of being a PM in a product consultancy is I get to experience a wide variety of different start-ups, 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 start-up 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 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 here first folks!
(Note: this is not an exhaustive guide and will most definitely be tweaked over time. This is just a simple framework that should be applied in the way most relevant to your situation)
- Immerse yourself in the start-ups' objectives
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.
2. Create a press release
We have adopted an approach called “working backwards” that is widely used at Amazon.
“We work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it” - Ian McAllister, General Manager at Amazon.
At Founder and Lightning, we encourage our Product Managers to create an internal press release announcing the finished product. It is "centred around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions”, as explained by McAllister.
We then keep iterating on the press release until we’ve come up with something concise that explains the end product well.
3. Workshop(s)
Facilitate a workshop with the client and their team including any stakeholders. At Founder + Lightning, we typically hold three half-day workshops and call this our "exploration phase".
The first workshop largely consists of getting to know each other better, discussing each person's roles and responsibilities within the project.
These subsequent workshops are spent analysing the business opportunity, establishing the main problems and challenging the client's 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.
4. Dive into your products tech
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.
5. Create a ‘Product Bible’
After our internal workshops, research and discussions, we then 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.
And that's it!
What do you think of this process? Do you have a particular technique?
