As a product manager, you’re guiding the creation of something new, untested, and potentially revolutionary.
And all the while, you’re attempting a delicate balancing act: using the opinions and talents of everyone with a hand in the project to build the best possible product.
You have reams of data and recommendations at your disposal to make decisions. But at some point, you just have to trust your gut.
Truthfully, you won’t always make the correct call. Mistakes are part of any job.
Still, you can minimize those lapses in judgment by creating a system that helps you make the right decisions and mitigates the damage from any wrong ones.
Here’s what goes into it:
Empathy and understanding underpin all of the points on this list.
You must be able to empathize with everyone who is involved with the product. That starts with the user. What do they need right now? Your goal is to think about the product from their point of view, understand their problem, and help them solve it.
But you also need to have empathy with your team — the people who determine whether or not your product is a success. This means being able to negotiate with engineering, sales, marketing, executives, and anyone else who has a hand in the product.
Everyone has different needs throughout the development process, and it’s your job as a product manager to understand and balance those needs.
The only way you’ll understand your users’ needs is by talking to them. Yes, that seems obvious, but I can’t stress it enough.
Your goal is to produce something consumers will buy. The best way to do that is to solicit feedback from customers — and then build accordingly.
If you don’t communicate with your customers, you can easily make incorrect assumptions about what they actually need.
For instance, many years ago at another job, our time cycle for building new features was about six months. One of our customers was a large enterprise company, and we didn’t have much contact with them during the building period. So when we showed them the new features six months later, they told us, “Oh, that’s not what we want anymore.”
The market had moved on, and we didn’t realize it because we operated in our own world for those six months.
With all the time spent guiding the project to completion, it can be easy to forget the customer. But most of your work means nothing without them.
You have to be attuned to the motivations of everyone who’s attached to the project.
Different people within the company will pressure you. Your sales team will push to make sales as quickly as possible in order to bring in revenue and commissions. Your technical team will want to spend as much time as possible building a superior product. It’s up to you as the product manager to balance competing interests.
That often requires you to act as an advocate for the people who are not in the room. Part of your job is to learn everyone’s viewpoints so you can explain and uphold the positions of people who aren’t present.
Over the course of a product’s development, there will always be other options you could have chosen. Choosing Option A means forgoing the possible advantages of Option B.
You can understand the trade-offs by answering these questions:
• How does this help my company long-term?
• How does this help us short-term?
• What is the level of engineering effort we need to put in?
One way engineering teams estimate effort for building features is by comparing it to the T-shirt sizings of small, medium, large, and extra-large. So if you choose to build an ‘extra-large’ feature, the trade-off implies you could have built two ‘medium’ features instead.
A framework I’ve used to choose between features is to give each one a ranking between one and five. Then, I choose the features accordingly by using a weighted average and picking the ones with the highest ranking. This quantitative framework is not perfect but does work most of the time.
The perfect product — one that meets every customers’ needs — is not going to be built overnight.
I’ve found it’s better to build something your customers can use in the short-term, while you work on adding more features. That’s usually an MVP, or minimum viable product. An MVP doesn’t have all the functionality you envision for the finished product, but it works. And most importantly, customers give you feedback on it.
Instead of taking the time to build everything at once, and possibly allowing a competitor to corner the market, you build in an iterative cycle. One feature goes up, and you allow consumers to test it and get feedback. With each cycle you add new features or improve what you already have.
Just remember that the key word here is “viable.” It has to work well, so it can’t be half-baked.
One of the most common pieces of advice you’ll hear when starting a business is that you have to be able to scale if you want to grow.
And while that’s true when it comes to the big picture, there are times when it’s more helpful to do things that don’t scale.
For example, when Doordash was just starting out, its founders didn’t build out an entire software infrastructure from scratch. They simply hired a few drivers, used Square for payments, and sent personalized messages to customers to get feedback. And they even moonlighted as delivery drivers when demand spiked.
Of course, none of that is scalable. But they were able to figure out whether their concept was working before they invested huge amounts of time, energy, and capital into it.
People tend to get swept up in the excitement of adding a cool new feature or functionality. It’s understandable, but just remember there’s more to creating a great product than adding features.
You have to make sure they’re actually operational, in all aspects of the word.
When it comes time to sell the product or release a feature, the sales team needs to be able to demo it for potential customers. And the system has to be ready so users can operate it almost flawlessly. If a customer calls your company with a problem, the support team should be able to offer a solution. The user guide and other product marketing collateral should be well documented for this feature.
Other aspects to be considered include how the feature will be installed, upgraded, rollbacked, billed, supported and investigated in case of an issue or protected against security vulnerabilities.
These are all processes that people tend to think will happen organically or can be taken care of later. But if you don’t operationalize features as you go, all the hard work you put into building them will go to waste.
When a consumer is making a decision between two similar products, something has to tip them in one direction or another.
Oftentimes, that’s the “wow factor.”
The “wow factor” doesn’t necessarily increase the product’s functionality. But it’s something people like. It may simply be more visually appealing or fun to use. Think of it as the icing on top, the extra component that creates a loyal following.
The messaging app Slack is a good example of this. Slack’s features are similar to other enterprise communication apps. But it looks nicer. It feels more user-friendly and intuitive. It even has a quirkiness to it, and users respond positively to that.
Everyone’s situation is different, and this checklist is by no means the final word on making product decisions. But by following it, you should be able to avoid many of the mistakes that plague product managers.
Thanks for reading!
Want to learn more? Get in touch with the Chronicled team here.