I’ve been a product manager at health tech startups for a few years now. Recently, I’ve been seeking books and articles about becoming a “good” product manager, especially in a startup setting. And I’ve come to the realization that this is not some magical secret held by the guardians of product management.
Managing product is simple, in that there a bunch of steps and you have to actually do all of them.
Doing the work, doing all the work, is hard. You have to invest focus and time into your work, and you have to care a lot about your output in the form of a product.
The products that you are building have to be things that you closely identify with your self-worth, in the organization and maybe even in the world.
If you don’t feel that strongly about it, you’re probably not going to do a great job managing product.
Assuming you care enough and want to do a great job, let’s outline what the work actually is.
The work of managing product consists of:
Understanding the things that everyone is asking for
Understanding where they’re coming from when they’re asking for all these things
Getting people to start making some of these things
Helping people finish making the above “some of these things”
Launching the things
Helping people use the things
Let’s dive further into each of these aspects of the hard work of product management.
#1 Understanding the things that everyone is asking for
You will need to understand deeply why everyone is asking for those things. This means:
- You know what all the aspects of the things are. This basically means you understand the feature, and you know how they are picturing it in their heads as fitting into some existing product that your organization already uses or sells.
- Why the people asking for them care so much about the thing. Curiosity and empathy are helpful here. Try to get in their head. What is causing them so much pain that they have to ask for this, or what is exciting them so much about the prospect of asking for this thing?
#2 Understanding where they’re coming from when they’re asking for all these things
You’re going to do this based on the goals of your organization. If you don’t know what the goals are, or realistically, the one thing you need to achieve this quarter, you’re going to be lost.
You need to figure out who it is that decides what the goals are, and you need to make sure you know how this is expected to be measured and that you agree that these should be the goals and the measurements.
If you don’t agree, speak up! Chase it down! Figure it out! And write it up for everyone to see.
#3 Getting people to start making some of these things
You will talk to talented designers and engineers about the right subset of the above giant pile of things, and you will ask them to help you make it real.
You have to be humble here because you’re not their boss. Whoever is running design and engineering are their boss.
Here is where you have to convince them that these are the right things to build at this time. You can use stories about how not doing this will create pain for your users, or stories about how doing this will create delight and value for your users. You can use metrics about reducing implementation time, or increasing sign-ups, or what have you.
Just have your act together.
Having your act together is really important at this time, and at all other times, lol. This is the secret of good product managers (and of good anythings), it’s that they have their act together.
This means they know what they’re doing, why they’re doing it, and they are organized in how they tell people.
If you don’t do the work ahead of time of thinking through what you will present to these makers, these doers, these engines of your organization, you will not be informed or persuasive. Therefore, you will not look informed or persuasive. You will sputter in front of all these people if someone has a question or a challenge. So have your arguments together, your documentation in order, and your presentation polished and fully prepared before you ask your talented peers to help you create something new in this world.
Don’t let this conversation drag on forever. Have your one or two meetings, and ensure that everyone that needs to be in the room or dialed-in is present. It will take you forever to get stragglers on the same page if they’re not with the group right now.
During your meeting when you are asking people for things, don’t get frazzled if people have questions, or it takes you time to explain to them why it is that you’re asking this of them. Be confident and be a fount of knowledge.
Not knowing why you are asking them for these things is a cardinal sin in product management. Never be in a position where you don’t know why you are asking your team for things.
They may not say it, but they will hate you for asking them to spend their life energy on something that you don’t even understand.
Be a good speaker when presenting and answering questions, and speak at a volume at which everyone can hear you. And if someone has objections that sound real, take that into account, and adjust your list of things you are asking them for accordingly. Document the changes and confirm them with your team. Be decisive and talk in such a way that people know that this is now the new plan on which everyone has to execute. Don’t accept excuses like “I thought we were going with X but now we’re talking about Y”. We are not just talking about Y now, we are now going to be doing Y. Decide, and tell everyone that that’s what we’re doing.
Assuming you get through this conversation and address all concerns and get everyone on the same page with the finalized list of what’s going to get built, you are now going to help your peers make these things real. They are going to start working on these new features, tasks, or bug fixes. Some of this work has to happen in sequence:
- Design might have to talk to the customer to quickly validate a requirement, or create an interface for engineers to build. Help them make that happen by scheduling the meeting with the customer if you have to. Make sure the conference line is functional and works well. Remember, this is about doing a great job at managing product, so don’t skimp on really important details like a functioning conference line. Test it ahead of time if you have to.
- You will have to write requirements for QA to write tests cases off of. Do a good job with this. Know the corner cases you’ll have to address, and explicitly speak to them in your documentation. Write documents that QA can access. How QA is able to access documentation should never, ever be a mystery to them. Be on hand if they have questions about how to write one of the test cases. Be responsive and respectful of their time.
- Engineers will have to create product for QA to validate. Be around to help them out with their questions. If they decide to simplify the implementation for some reason, be there to weigh in on this if you’re needed, and definitely know that this is happening. And of course, document any changes.
There is also some leftover work here, that you absolutely have to do, which is communicating with the people who asked you for the things.
- You have to let the ones who are getting stuff know that they’ll be getting stuff.
- You have to let the ones who are not getting stuff know why they are not going to get their stuff this time.
- If they will get it later, tell them that.
- If they will never get it, tell them that.
- If you don’t know, tell them that.
You need to help all of these “askers of things” trust you. Don’t be a flake, and don’t let things fall through cracks. It is too easy to ignore the things that don’t get made and the people who asked for them. It is hard to document things in such a way that you have your requests observably sitting in a clear, comprehensive manner in some non-overwhelming location.
Do the work of figuring out how to document what is happening and why, and what is not happening and why not.
#4 Helping people finish making the above “some of these things”
Finishing the work of making the things you decided had to be made right now is an extension of Step #3 above. This will require back-and-forth from each of your teams that are building things.
It is your job to help them finish the process of making it real.
When you help them make it real, this is you actually helping them help you make it real.
Your job is that this thing ships. It is critical to get this work completed, and minimize the starts and stops to the fullest possible extent.
I will remind you that again, people lose motivation when you don’t have your act together. So, have your act together. Get your tickets ready in your ticketing system, each with sufficient information, and get your PDFs of the interface uploaded into the tickets, and get your documentation in order so that QA can do their work on time so that you, yes you, can ship bug-free software.
#5 Launching the thing
Launching a product is about focus, stamina, and teamwork, not magical knowledge that someone else has that you don’t have. It is the sum of all the parts thus far, and the tying of the bow around it.
Launching your product will mean writing release documentation and telling people that it’s going to happen. If you set a date, make sure you tell people whether you’re planning to launch on that date. Don’t wait for three different people to come to you to ask whether it’s still on schedule. You should be pushing out these notifications, not waiting around for someone else to tell you whether it’s going to happen.
If you’re launching something of a big enough magnitude, i.e. a new product or a big new feature, you might work with customer-facing folks and with marketing and with sales, to make sure that your customers and your market know about this new, real, useful, valuable thing you are releasing into the world.
All other launches will probably also involve some kind of communication out to the customer, whether that is an internal user or an external user. Make sure you do this work of letting them know that their thing is now ready. Make sure they know what benefits they will enjoy if they use the thing.
- Will it now save them 30 minutes to do some menial task?
- Will it enable them to do their work more safely?
- Will they now be able to service 20% more people in the same amount of time?
Figure out the benefits and lay them out clearly for your customers.
As you launch, you also need to do the important work of celebrating, and of acknowledging everyone who created this product or new feature or critical bug fix. This was a team effort. It is always a team effort.
There are always people who have given their life energies to making this happen, to creating this thing that you asked them to make.
Give them their due, and know that you have been successful in your launch because of them.
#6 Helping people use the thing
Now that the thing is out, you need to ask your users how they are using them, and if they need any help. Sometimes, all it takes is a little bit of training. Again, have your training materials ready. If you think they’ll read documentation, write documentation ahead of the launch and ready to share it with them. If you think they’ll watch training videos, budget for time and people to help you produce these while you plan your post-launch activities.
Sometimes, sharing this training material will actually be part of the launch. Sometimes, much ado may not be necessary. Make the necessary judgment calls when deciding how deeply you want to get into training, and err on the side of over-communicating how it is that they will be using this thing.
Check in on them after a day or two, and see if they’re using the thing. You might want to sit with a user and watch them use the thing, or use the thing with them. It is your job to make them comfortable with the thing you’ve made.
But if the thing is bad, they will never be able to be comfortable with it. When this happens, it is your job to 1) know how you are going to fix the thing, and 2) tell them how you are going to fix the thing.
You will have to bring their feedback back to your team, and you will have to do this in such a way that you are not blaming anyone or making anyone feel bad.
This part is hard. You have to clearly state what went wrong, and then immediately, you have to refocus on building a better future for your users, with the help of your talented peers who are the ones with the actual power to create new things in the world. Make sure you have your requirements right this time! You can only fail so much.
In B2B businesses, you actually have the luxury of failing less, if you really listen to your customers and properly document what it is that they have asked you to do. This doesn’t mean you give them everything they asked for. It means that you use their requests as a way to know their problems, and you institutionalize this knowledge in good documentation. You disseminate your knowledge using good communication systems.
Clearly, all this is work measured in hours, days, weeks, and months.
You have to build systems that help you put in the hours of actually doing the work, systems that make doing all this work with all these people a little easier.
I’ll get into the systems that help you do the work in later posts.