In this article you will find:
People often ask Product leaders: how did you go into product management without knowing anything on tech, specially in a SAS startup? Well, our job is not to define how our code or architecture is defined, but rather to ensure we tackle the right problems in the best way possible.
Of course, a big part of that is: having the adequate code implemented, and ensuring that your data flows in the right way. And that is where documenting and discussing ideas becomes golden, and is when a Product Proposal takes relevance.
How to write a Tech Product Proposal?
Every industry calls it different: brainstorming, problem solving, strategizing, product proposals, etc. But it all amounts to the same thing: find a way to express your idea/problem and have a set of intelligent people ask you questions, challenge your assumptions, give your ideas, and test your paradigms.
In Truora, I have learned that: writing down your idea is half the magic of this process. When you write something down, you put it to the test. You simplify your ideas, and you polish your thoughts. It is a way to give yourself feedback. From then on, it's open to the rest.
So here are some advice for writing your tech product proposal:
The more diverse the team reading your ideas the better.
Remember: you aren't looking for approval, you are looking to catch that blindspot that you couldn’t think off. Blind spots are the enemy of any strategist/product manager. Because they are usually things that exist and will affect your outcome, but you had no idea they were there. So, asking for feedback on your ideas document (let’s call it: proposal) is exactly for that: to cover your blind spot.
The process doesn’t end there: it is not just 1 simple feedback meeting. But rather: as many as it takes so that all stakeholders:
(1) understand the problem and agree with it.
(2) like the solution and believe it to be the most efficient.
The main job of a product manager is the 1st point: explaining the problem and detailing why it is a priority. The 2nd job is more dual: both the product manager and an engineer have to work hard to understand customer and user preferences, and come up with the best solution.
Most teams focus 90% of their time in the 2nd task. Forgetting that solving the right problem is more important than having the best solution.
The takeaway we can give by having worked on a product for a few years: never underestimate the power of a non-biased discussion. Most of our great solutions and innovations have come from those comments and ideas of the most unexpected sources. And also: be that person that cares enough to read ideas and give back constructive feedback. 👇👇
Did you like the article written by our Product Leader?👇👇
