As a product manager, when you discover a problem, you’re more likely to believe that you’ve uncovered the symptoms. It may be because many customers talk about the same problem, so you assume you’re aware of the details.
For example, imagine you’re building design software. Some customers tell you that they want your software to make it easy for designers to share creatives with the marketing team. So, you go ahead and build a link sharing feature. You’re confident that this is the correct solution.
A few months later, your trusted customers explain to you why they need a ‘design review’ process built inside your product. They want some stakeholders in the marketing and design teams to approve, reject, and share feedback on creatives.
Now, you’ve got to pivot your solution from link sharing to design review.
What happened? Before building the solution,
- you failed to understand ‘why’ these customers want a ‘design sharing’ feature
- you didn’t enquire what they will miss if you didn’t build this feature
- you didn’t think how building this feature will affect existing or new users
In short, you didn’t fall in love with the problem.
Why is it necessary to fall in love with the problem?
The reason is simple — when you fall in love with something, you become curious. You want to learn more about the person or thing. From a product-context, this curiosity will help you uncover the root-cause or symptoms that lead to a ‘problem.’
The magic wand that can help you get there is good documentation.
Many people mistake good documentation for writing down the perceived problem, along with the next steps. It is much more than that.
Good documentation is the best way for you to get started with your journey into the ‘problem land.’
Good documentation
- challenges your understanding of the problem by making you ask a lot of ‘why’ and ‘what’ questions
- helps you become aware of your blind spots
- enables you to think of solutions that will make your users successful
- makes you a better thinker
- acts as the go-to guide for all the stakeholders in your company.
Good documentation is your second brain.
My friend Shankar discusses why companies should build a documentation-first culture in this blog post.
Here’s my favourite part:
I think if things aren’t documented well, especially in a business that’s growing like crazy, it doesn’t just affect the teams’ abilities to build things and ship fast but also slows down the learning for new hires and prevents them from understanding the historic context of org, tech and product decisions.
The challenge is in building a documentation-first culture when everyone is already stretched to do too many things; making documentation a habit, sort of second nature for everyone. The challenge is in selling the value of writing and having things recorded down for non-immediate benefits.
Shankar Ganesh
If you want to become a better writer and thinker, befriend the process of documentation. It is a rewarding experience.
P.S At Rocketium, every thought, idea, or problem begins with documentation. Everyone, right from the product, engineering, marketing, sales, and customer success teams, follows this process.
If not for this experience, I would not have learned the value of documentation. 🙂
Akkshaya Varkhedi 