How to build the wrong product, semi-accidentally
Ask your customers what they want, then write it down, then build it, then call them back and get a dial tone
It is tough to decide what product to build. Developers normally think a product manager’s life is easy because they just shuffle information between parties, but this isn’t true. Sometimes, they forget to shuffle the information.
The job is hard because product managers must decide what to work on to build the right product. Developers only have to worry about building the product right. Developers normally talk to fewer people and operate on less information than a product manager does, and there are fewer ways to do things right than there are potential ways.
It can be difficult to figure out who to listen to when you are a product manager, and there are multiple stakeholders, dozens of projects, and many competing priorities. One easy way to figure out what product to build is to use the following algorithm:
Figure out who matters.
Listen to their opinion.
Execute their opinion.
This is a very complex algorithm, even though only three steps exist.
Figure out who matters
Figure out your company's most important people and what they care about. This is normally pretty easy:
Who can fire you
Who doesn’t like it when you don’t agree with them
Who can you not criticize
Figuring out who the most important external people are is a bit harder:
Who appears to have a close relationship with the internal people
Which customers drive most of the cash flow within your business
Who is good at yelling and getting things done after the yelling
Who is the longest, largest, most strategic customer, or who you just broke badly the last time and are trying to make up for
Listen to their opinion
Many times, they will tell you their opinion directly. Other times, you must guess what it could be by expressing other opinions and seeing which ones they react strongly to.
Execute their opinion
Then you do whatever the opinion of the top-ranking member of the Most Important People club.
Then your life looks like this:
hear about a “critical” item
write it down
take it to the developers
have them work on it
get another call about another critical item
stop the developers and get them to work on the other thing
get a call from the first critical item asking for status
call the developers and ask for the status on the first thing
repeat
You may have heard that you should build a product roadmap using all your intelligence, customer data, actual conversations with customers, anecdotes from the support team, outside research, and intuition. This roadmapping exercise is meant to develop a dynamic and intelligent plan to build the product you need.
This is wrong; you should build products based on GPSing, not roadmapping.
With GPS-ing, you defer responsibility of where the product goes to one person and then just adjust the course as traffic moves. It isn’t your fault that there was traffic there, or that the bridge was out, or that your destination changed. You only need to know where the next turn is - it is the one the important person told you to take, after they told you to miss the last one.