This is an attempt to distill down the set of principles that guide my approach to product. I'll be the first to admit that I am skeptical of product frameworks. There is not a one-size-fits-all approach to product management. Everyone has their unique take on product management. So take what I say here with a grain of salt, but I hope you find it useful.

Velocity is one of the biggest indicators of the success of a product. The same is true for a Product Manager's career. Not talking about velocity in terms of tickets closed. But rather the speed by which you start working on an idea and how quickly you work through that idea. The glut of frameworks has made the product process too precious. Things have to be just so before you can get underway. But no amount of prep work and planning will ever beat hard, sustained work. People say to "work smarter, not harder". But real success comes from working smarter and working harder.

The typical PM's calendar gives the impression that they are a meeting manager rather than a product manager. Most of our time is occupied with talking with others and putting out fires. But ideas need time. Lots of time. Long periods without distraction are where you can solve your customers' biggest problems. Find ways to win back your time and then guard it. Don't let people take it away. Invest that time into your biggest, boldest ideas.

These first two sum up most of my thoughts on how to do product, and work in general. If you want a deeper dive into either of these check out Paul Graham's essays: How to Do Great Work and How to Work Hard. These capture everything I would want to say and more on what it takes to build great products.

Product managers should build in public. Share with others what you are thinking about and working on. Use a culture of writing to share what you are chasing so that others can weigh in and collaborate. Products built in the shadows are often failures. Building in public allows you to share your enthusiasm for the future. It helps turn others into evangelists for what you are building. It also exposes flawed thinking before it becomes embedded in the codebase. Unless you are building something truly novel, there is no downside to building in public.

PMs should take a similar approach in their career. Talk about what you are doing with others in your network. Blog about your unique approach and insights. Share what you believe so that you can find those who are in your tribe. Create a body of work that shows the value you bring to the product world. The more you share, the more feedback you get, and the faster you grow.

Here is one that will make many product people cringe. Most frameworks today focus on testing and validating assumptions before you build things. I agree you should iterate and validate. However, I have found it hard to do that when what you need to validate does not exist in the actual product. I'd much rather get the thing out there and hear from customers about what does work. What additions need to be made. Or what we need to take away. Sometimes it isn't practical or possible. In those cases, you should still seek to mimic things being in production. Create a no-code prototype or a simple spreadsheet. Get customers to use that in place of their current tools. Iterate on it with them (ideally on a daily cadence) until it works better than their current tools. At that point get it into the product. However you do it, until customers are using it in production, it will be hard to say if you actually solved their problem.

This goes hand in hand with the previous one. I have always liked to operate in this way but didn't know it had a specific name until I heard Barry McCardel talking about it. I talk about it as taking the journey with the customer, he calls it "commitment engineering". Whatever you call it, it is a way to keep in lockstep with your customer and ensure you are building the right things. Once you have a pain point to solve and find a customer with that pain you get into a commitment loop with them. The first ask is for them to spend time telling you about their problem. It is all about confirming that you are on the right path. Then you commit them to meet again to review some potential solutions based on what you heard. After that meeting, you commit them to meet with you again to look at some prototypes (ideally an actual piece of software ⬆️). At that point you get them to commit to using the prototype and giving you feedback. You get them in this cycle of usage and feedback until it is solid enough to meet their needs. Then you commit them to only use your product and leave their other tools behind. And finally, you commit them to paying for the thing you built. There's tons of variation in how this plays out in the real world. But the key idea is to take the journey with the customer and get them to buy in at each step of that trip. If they don't buy in then you don't keep building. You go back to the drawing board and figure out another vector of attack.

Having worked with a lot of operations-heavy customers, I have learned that your product is a very small piece of the puzzle. The things customers do before they use your product and the things that come after, often matter much more to their business. You need to ensure that you fit into their workflow. You can't blindly intake data, process it, and then send it out. You need to look upstream and understand how that data was generated. Get boots on the ground and go do those generating actions for yourself. Likewise, you can't send data out without thinking about how it will be used downstream. Make sure you are actually solving the customer's main problem. And make sure you are not causing other problems along the way.

GitHub CoPilot is my favorite example of this principle. They didn't build CoPilot because developers were asking for AI tools. They built CoPilot because developers didn't have enough time to code. They were spending all their time in meetings, advocating for budget, testing, etc. CoPilot was created to ensure they were super effective in the time they did have to code. It solved a problem that had nothing to do with what developers were looking at on the screen.

As much as we love our products, the average user groans when they are told they have another tool they need to use. Our product represents more work and learning for them. If we want to win them over then our tool needs to empower them. It needs to give them time back, give them the ability to do things they couldn't before, and create the chance to work on higher-value things. For our product to be successful, our product should make our users the hero.

This one seems obvious but often falls to the wayside as PM's time is eaten up by other commitments. It's hard to iterate and improve on a product when you do not understand how it currently works. In an ideal world, you can use your product to help you build the product (like this example from dbt). I've been fortunate to work at three companies with strong data tools, this has allowed me to live in the product daily. If this approach isn't practical for your product, you can and should still be in it each day. Go through order flows, interact with the API, submit support tickets; do all the things your customers are doing in the product. And when something feels off, make it better.

Another obvious one that often gets lost in the PM time crunch. If PMs are going to be the voice of the customer in a business, they need to embody the true voice of the customer. There are a lot of great tools for understanding customers. There are tools for collecting customer feedback, others for observing their actions, and some that let you review calls. But none of those beat direct communication with a customer. Look for ways to get in contact with customers each day. Hop on sales calls, join an onboarding session, or pick up a support ticket. Get into situations where you can hear what customers truly think of the product. Be there when they talk about the places where they feel the most pain. A great way to hold yourself accountable for this and track what you learn is through customer logs. There are versions of this both for what you learned from customers and what you did for customers. I recommend using both of these and updating them at least weekly.

In a general sense, Product Managers are the voice of the customer in the business. But we often take that to mean we should root our worldview solely in the customer. But customers are only half of the puzzle. In the life of a PM, engineers are as important as customers. After all, they are the ones who actually fulfill the needs of customers and the business. I like to think about this concept as a spectrum. The measure for this spectrum is empathy, specifically empathy for customers and engineers. A lot of PMs skew to the customer end of the spectrum. But to be successful we need to sit right in the middle. We need to understand the pains and needs of our engineers as much as we do those of customers. We need to advocate for our engineering teams as strongly as we advocate for customers and the business. We need to ensure we do right by our engineers and understand how to best use them. Especially because customer wants are endless, but engineering resources are finite. So we need to ensure a proper balance to deliver what is most important.

There are hundreds of ways to define a product strategy, but this is the one I like best. When talking about product strategy, I use a hierarchy. The highest level is what you say to people, and how you inspire them to your cause (some may call this a product vision). The next layer is how you make decisions and how you decide what to build (for instance you could focus on comprehensiveness or continuity). And the last piece is your roadmap, what you actually build based on the other two pieces. All three of these are needed for a sustainable product strategy. (I wish I could remember where I first heard this so I could give proper credit, but it is lost in the black hole of the internet.)