How to Break the Rules of Product Management

Product Management can be an amazing, fulfilling career. It’s multi-disciplinary, intellectually challenging, and often a great fit for people who bring a mix of analytical, creative, and social skills. I love it.

But I’ve noticed lately that it’s become increasingly common to see product managers fixate too much on formal methodologies and role definitions. A lot of these practices include useful information, but they can also become a form of in-group posturing and empty symbolism. The Product Management Way manifests through certain terms, acronyms, and frameworks we use. But it hasn’t really risen to the levels of excessive credentialism or occupational licensing, thankfully.

It makes us feel good, like we’re a serious craftsperson that uses well-defined techniques and tools based on a long industry tradition passed down one generation to the next. We work around designers and software engineers all day, and they’ve got all the cool toys and tricks, so it only makes sense that we should too.

As product managers, many of us read the same books, follow the same thought leaders, use the same work tools, and generally have similar job responsibilities, more or less. But the danger in all of this is that we often confuse the lore of product management as a fixed set of rules. We start believing in the “right way” and miss the fact that great product leaders like Marty Cagan, Ken Norton, and Shreyas Doshi are writing things that are purposely accessible and must compress their decades of experience down into a reduction, something that might miss the pragmatic, unglamorous, and downright messy ways that people find success and get shit done.

But that’s not to say that you shouldn’t learn how to play house. Learn the dogma, learn the buzzwords, learn the methodologies and all the techniques. Try them for yourself. See what works and what fails in different scenarios.

Learn the rules so you can break them. Then create your own style, your own Jeet Kune Do.

One of my favorite interview questions for product managers is “tell me how you broke the rules of product management to get something done.” Usually the best PMs laugh before they answer, because they know just how many times they’ve had to do this. And they often have more stories than we have time to discuss.

So I thought it would be fun to share some popular product management rules, so you can be ready to break them at the right time.

---

Rule 1: Product Managers Shouldn’t Create Mockups

In an ideal state, you might have a balanced, cross-functional team with a product manager, 5-6 engineers, and a designer. You start together, maybe with a product manager writing up a brief one-pager and initiating some discovery activities early on, getting your designer and engineers (or at least your lead engineer) involved in shaping the product/feature from the beginning. You engage in customer discovery, and gradually add fidelity to your requirements, UI designs, and engineering plans, even after you start building the solution. It’s all continuous, agile, and collaborative.

The problem is—you’re not going to have this perfect setup every time. You’re not always going to have a good, healthy offensive line that can protect your quarterback for 4 seconds on each play. You’re going to be on a team that doesn’t have a dedicated designer or your designer is going to be tied up with other priorities. At this point, you can just decide to wait around until the conditions are perfect, or you can keep things moving forward.

Sometimes, you need a quick concept mockup for a very early idea you’re floating around and you need to gauge stakeholder interest. Sometimes, you need a super straightforward quality-of-life enhancement that is so blatantly obvious and low risk, it would be a crime to write a JIRA ticket to get a mockup created. Sometimes, you need a mockup to look at so you can grapple with some long-term ideas that are fuzzy in your head. Not everything needs to follow “the process.” Not everything needs to be top-notch, production-grade design.

I teach all my PMs how to create their own quick and dirty mockups if they’re interested in learning. I’m not talking about low-fidelity Axure/Balsalmiq wireframes. Everyone should already be able to do those. I’m talking about something that looks like the product you already have, that will elicit strong reactions and opinions and drive clarity. We usually start with the Chrome Inspector first, get comfortable with our design system and React component library, and then level up into some layer-based, non-destructive design in Figma or Sketch. If they want to take it further, I’ll teach a bit of interactive prototyping with Invision / Adobe XD / Figma.

Of course, the goal is not to replace the designer. It’s to learn how to use visual artifacts to improve your own thinking and to quickly test ideas before you have fully-formed requirements, or something for the many cases where your engineers shouldn’t need designer-quality mockups to execute minor enhancements.

---

Rule 2: Product Managers Shouldn’t Give Estimates Without Engineering

Oh man, I might get in trouble for this one…

We know every product manager has to have a roadmap.

It doesn’t need to be a detailed gantt chart or timeline with 30 projects and precise dates listed out over the next 2 years (please don’t do this). It could be a Now / Next / Later roadmap like this:

But most product managers, especially (but not only) in B2B software, are going to get pressure from stakeholders to provide target delivery dates for certain things. As Marty Cagan points out in this excellent post, “In all businesses there are occasional situations where something important must be delivered by a specific deadline date.”

In these situations, you need a “high-integrity commitment” and you 100% must involve engineering in generating these dates.

But you’re also going to run into hundreds of other situations where you don’t need to provide a hard commitment, and the effort to gather a vetted estimate from engineering isn’t worth it. You’ll be in a call with your executives and they’ll ask about something. Or a big customer will mention something small on your Now-Next-Later roadmap. The purist in you wants to resist giving an answer and just tell everyone “I’ll get back you on that.”

But that’s not really going to cut it.

There’s going to be a time where you need to make a judgment call on the spot, and if you don’t, you’ll immediately lose the respect of the other stakeholders in the room. They don’t expect you to have memorized, accurate, vetted timelines for every tiny line item on your roadmap. They expect you to have a good enough sense of your team’s capacity and velocity that you can make the call on the spot.

That’s why it’s good to build this muscle yourself. Spend time breaking down projects with engineers and understanding why things take time. Practice giving timelines with the right disclaimers and with a healthy buffer. Build a lot of things over the course of years, with a lot of different teams, and you’ll grow an intuition around sizing and difficulty.

---

Rule 3: Product Managers Own the Why & What, but not the How

This is such a silly rule that I’m not even sure how it entered the zeitgeist.

There’s this strange misconception that product managers are just responsible for setting a vision, figuring out what needs to be done, and then the designers and engineers work through all the messy parts where they figure out how it all gets delivered. It’s almost like a 4-hour Work Week fantasy or something.

This couldn’t be more wrong.

In my experience, the best product managers are extreme craftspeople who are curious about how software is built. They get into the weeds and learn as much as they can. And they don’t limit their ideas to things that are directly deduced from customer problems. Their ability to anticipate the technical challenges and opportunities allows them to make better long-term decisions.

I find that product managers who treat the entire “how” as an engineering responsibility have some common pitfalls:

1. They more often ask for unrealistic features that will take too long
2. They require significantly more volleys back and forth with engineering during discovery
3. Their products are more likely to accumulate technical debt, usually because of poorly defined domain models and key concepts
4. Their teams build more one-off enhancements that lack reusability / platform approaches

For PMs on my team who are more curious about the technical side, I like to start with training on Domain-Driven Design concepts. Then we get into the foundational knowledge around data structures and databases. We teach PMs to use Swagger/Postman to test APIs. Depending on what the PM works on, we might even get into algorithmic complexity, indexing, and caching.

I do not believe every product manager needs to know these things, but I do see a noticeable difference in the quality and elegance of solutions that come from product managers who deeply understand how software works. I see better relationships with designers and engineers. And I see more innovative, boundary-defying products.

---

I’ll warn you now that if you break these rules, you might offend some sensibilities. You might get pushback from your team.

But if you never break these rules and you always stay in your lane, you’re going to be waiting around for the happy path while the scrappy, pragmatic, multi-faceted PMs are busy getting shit done.