A question that came up from my post about handling B2B SaaS feature requests was whether SaaS startups should have a public “suggestion box” feature where users can suggest ideas and other users can publicly vote on them. Accepting feature suggestions is helpful, but if votes are public it may box you into a corner where you must ignore what the community wants (like faster horses) because it’s unstrategic.  This can cause customer-relations challenges or PR problems. So I generally prefer to avoid publicly quantifiable feedback about roadmaps, because it limits your flexibility to do the right thing for your business.

But this discussion got me thinking about future-looking communication with customers in general, especially in public. So it’s a good time to write about how I handle the inevitable requests from customers, salespeople, press, and others to share a public product roadmap.

My advice: don’t do it!

Public roadmap sharing: what could go wrong?

In my experience, public sharing of roadmaps usually hurts more than it helps. Here are a few reasons why:

• When (not if!) you change the roadmap it will annoy customers. Humans are more upset by unexpected losses than unexpected gains. Even if the feature list and priorities stay constant (which they won’t—see below!), the dates inevitably change because it’s hard to perfectly predict timing. So instead of customers being thrilled with great new functionality, they’re annoyed that you’re late or because you cancelled a feature they wanted.

• Limits your flexibility to tweak roadmap to maximize revenue. In every B2B PM role I’ve ever held, I’d often tweak the roadmap in response to market conditions like beating a competitor to market, internal constraints like if an important employee quits, or tactical sales reasons like accelerating a feature to close a big deal or preventing churn by throwing a bone to a customer. Having a public roadmap makes these changes harder.

• Sometimes you cancel features or proposed products. It’s very common that, as you learn more about a feature it will cost more and/or have less value for customers than you expected when you first put it on the roadmap. Having the flexibility to silently cancel a planned feature is very helpful. Nothing sucks more than having to ship a feature for one customer you promised it to when you already know that your other customers won’t use it, or if it costs 3x what you expected.

• Your competitors will use it against you. Your competition will study your roadmap. They will have months of head-start in marketing messaging, sales tactics, etc. so that when you finally ship the features the competition has been trashing them among your prospective customers. Also, they’ll tweak their own (private) roadmap to try to beat you to market, to beef up areas of the product where you’re challenging, and to hone in on customer segments that your roadmap is neglecting.

• Journalism. No topic is easier for tech writers than “Company X slips product Y by N months”. The story almost writes itself. Just add quotes from customers who are annoyed (see above) and hit publish. And then when you finally launch, the headlines go like this: “Long-Delayed Product Y Finally Ships”. The press has a way of turning good things (transparency, agility) into bad (delays, broken promises). Don’t make it easy for them.

• Legal & accounting risks. When you don’t exactly deliver on your roadmap, customers can sue you! There’s a whole part of securities law and disclaimers designed to avoid these lawsuits. Even with the right weaselly disclaimer, there are accounting rules that may force you to defer recognizing part of the revenue from a deal if a customer has been promised features but they haven’t shipped yet. You *really* don’t want to be the person who caused your company to miss its quarterly numbers for dumb accounting reasons!

Of course there are always exceptions to the don’t-share-roadmaps rule. You can use a public roadmap to scare a competitor away from a space or to mislead competitors into a false sense of security. You can publicize a roadmap to generate buzz or to generate sales interest. And so on. But these are exceptions, not the rule.

Instead, privately share a prioritized list of possible features

Instead of sharing a roadmap, even with trusted customers, I’ve found that a better approach is to share a coarse-grained prioritized list of 10-15 proposed features. Then I ask the customer for feedback about the features and priorities, and use it as a jumping-off point to better understand their needs. I often say something like “Here’s a list of features that, based on feedback from you and other customers, our team is considering building.” and then I ask for feedback:

• “Are these the right features for your business?”

• “Are there things we should be working on sooner vs. later?”

• “What’s missing from this list that matters a lot for your business?”

• “Are there things on here that you think aren’t helpful for you?”

This backlog-feedback approach has a lot of the benefits of roadmap sharing without most of the downsides because you’re not actually committing to specific features nor dates. With our best customers, I like to repeat this exercise at least once per year. This gives us a chance to show off what we’ve shipped from last year’s list, to understand how the customer’s needs have changed, and to build a collaborative relationship where the customer feels bought into our future plans because they had a part in building those plans. By making a customer into a collaborator, everyone wins.

Doesn’t Sales need a roadmap to close deals?

Salespeople often worry—justifiably!—that your company’s current products and features are not sufficient to land the easiest or most profitable deals in their pipelines. They often ask to share roadmaps for many reasons, including: because SaaS deals take a long time to close so they want customers to know about the product they’ll have when the deal closes; because competitors are often sharing their own (usually untrustworthy) roadmaps; or because they believe that if we just commit to one specific feature then they can close a big deal.

What I’ve found after 10+ years working closely with many enterprise sales teams, is that it’s helpful to understand *why* sales prospects care about roadmaps, especially given that all intelligent customers will be understandably skeptical about future-looking marketing claims of tech companies. As I wrote in a previous post:

How you communicate with and relate with a customer often matters as much as what and when you deliver. An enterprise customer has often made a career-risking bet on your product. The biggest fear of your customer isn't that you'll be late. It's that you'll ignore them and *never* solve the problems you promised you would—just like every other B2B tech company since the dawn of time. If you can't solve the problem right now, at least spend the time with the customer so that they know that you understand the problem and really care about will solving it in the future. SaaS is not about today's tech, it's about the promise of a better future. Make them believe!

With that in mind, customers want to know what you’re planning, and want to believe that you’re competent enough and motivated enough to deliver it. They don’t need dates to believe this!

So I tend to push back on salespeople who say they need a roadmap in order to close deals. I’ll often walk them through the downsides of roadmap sharing discussed above, and ask the salesperson: do you want the customer to think in 12 months that you lied to them, because our plans will almost certainly change in the meantime? Most salespeople are savvy enough to realize that it’s in their best interest not to get caught selling the customer something that our company won’t deliver.

But if a deal is large enough, then I will volunteer to get on the phone with the salesperson and the prospect and run through a simplified version of the same process I note above: share a list of features things that “our team is considering building next” and asking the customer how these things align with their needs. This is almost always a productive conversation that builds our future-facing credibility more than a probably-vaporware roadmap that the competition provides.

Paul Graham, in his popular essay How to Argue, defines a taxonomy of arguments: from Level 0 (“Name-calling”) to Level 6 which is an evidence-backed refutation of the opposing argument’s central point. Paul’s intended audience is probably engineers—especially young ones—who are smart and opinionated but who may not have strong interpersonal skills. For those folks, it’s reasonable advice.

But it’s not ideal advice. My experience leading PM for many tech startups has taught me that arguing isn’t the best way to resolve disagreements. Unlike low-EQ engineers, selfish salespeople, harried executives, and grumpy support reps, Product Managers are often the most socially adept members of the team. This post explains how you can use EQ and savvy to resolve most disagreements, usually without arguing.

Lessons from Open Source

A surprising source of resolving-disagreement skills has been my weird (for a PM) hobby: I contribute to open source projects. For example, in my spare time I’m a member of ECMA TC39: the standards committee for the JavaScript language, where I’ve got a PM-like role co-leading a team designing JavaScript’s new “Temporal” built-in date and time API.

Some open-source projects are contentious, like the Linux kernel where BDFL Linus Torvalds will call contributors stupid. But most open-source projects I’ve worked on aren’t like that, because (also unlike the Linux kernel) most open source projects really need help! Dissing contributors is a sure way to quickly end up with no contributors.

Instead, my open source work has been a stress test of influence without authority skills, because there’s no boss, no BDFL, no P&L, and no deadlines. The only way to make progress is to convince everyone else. Given these constraints, the only way to make fast progress without fracturing is to figure out how to resolve disagreements without demotivating contributors.

The best open-source teams develop a collaborative problem-solving style that allows teams—including senior engineers and others with strong opinions—to efficiently resolve hundreds of disagreements per year with very little zero-sum, adversarial argument.

In my “day job” leading PM for B2B startups, I’ve tried to apply the lessons I’ve learned from my open-source work. The rest of this post explains specific techniques for how to resolve disagreements quickly with minimal rancor.

A caveat: resolving disagreements without fighting is a difficult art to master. I’ve been practicing these techniques for many years and I still don’t always get them right. So don’t be discouraged; just keep at it and success will come.

Don’t argue; instead, resolve disagreements

My overall advice in this post is to shift your mental framing from “win arguments” to “help teams resolve disagreement”. Your goal should be to be a catalyst to help your colleagues make good decisions, which is not the same as winning arguments!

A focus on “winning” an argument is problematic because it requires that someone must lose. Humans hate losing! When people lose an argument, they can be unhappy, and sometimes bitter or resentful. This hurts team productivity and cohesion, and may make it harder to resolve future disagreements. Getting to a good result while minimizing squabbling isn’t just politeness; it’s a hard-nosed business strategy to avoid hurt feelings that will reduce your team’s long-term productivity.

Instead of resolving disagreements via zero-sum fights, I’ve had better outcomes by recognizing that arguing is just one way (often a sub-optimal way) to figure out solutions. A better way is to reframe your job-to-be-done—to yourself and others—as “resolving disagreement”, which is inherently a team sport. Instead of someone winning and someone losing, you’re all working together to figure out a good solution.

The rest of this post outlines techniques that I’ve used—and helped my colleagues learn and practice—to put this “efficiently resolve disagreements” goal into practice.

Listen before disagreeing

Asking questions before disagreeing is important, but even when you’re not asking questions it’s helpful to wait to communicate your opinions until you hear what other people think. Why?

• If you listen to them, they’ll listen to you!

• Their arguments may convince you, in which case they never need to know that you previously held a suboptimal opinion.

• If you’re senior, hearing your opinion first may cause others to change their opinions simply to appease you, instead of presenting their best ideas.

• Having more information about opposing points of view lets you build a more convincing case, and gives you more time to build it.

Before disagreeing, ask questions

Ask questions before expressing disagreement! Over the years I’ve tried to train myself to have a “question reflex”: whenever I disagree with someone at work, I try to make the first words out of my mouth be questions to learn more about their point of view.

Asking questions has practical benefits:

• Many disagreements are actually misunderstandings. You might end up agreeing with others’ positions once you understand them better.

• Even if you don’t fully agree, deeply understanding the other side may expose a synthesis or compromise solution that lets you both achieve your goals.

• Asking questions makes it clear that you’re investing time to engage with and deeply understand others’ positions. This makes it more likely that they’ll give your opinions the same respect.

• When you later present your own opinions, you can frame them in concepts and language that your colleagues used, so that you don’t require them to work as hard to understand—and hopefully agree—with your position.

• If you agree with part of others’ position, you can narrow the scope of the disagreement. Smaller arguments are easier to resolve.

Yes, and…

Instead of saying no or stating disagreement, it’s often helpful to adopt the “Yes, and…” communication strategy that’s borrowed from improv comedy. If you can frame your opinion as an extension of someone else’s ideas instead of a refutation, then your own opinion is more likely to be accepted.

Most humans (especially people who haven’t read this post! 😀) view disagreement as a threat. After someone knows you disagree, they may solidify their positions or become defensive. But if it sounds to them like you’re on board with their idea, then you’ll have an easier time getting their support.

For example, imagine that your sales team is demanding that you provide them with a product roadmap that they can share with a potential customer. You know (perhaps because you read my post about handling customer feedback!) that you don’t want to do this. But instead of telling the salesperson “Sorry, we don’t share roadmaps”, instead you can say “I’m so glad you’re thinking about this. Who’s the customer and what are their interests? I can help you craft some talking points about what we’re considering to build next, but without committing to specific dates so that we can have flexibility to change things around later.” This isn’t exactly what your salesperson asked for, but you’re likely to get better results because you’re engaging with their suggestion and extending it, rather than rejecting it.

Emphasize agreement first

Many humans tend to focus on where they disagree more than where they agree. I especially see this behavior in engineers, accountants, and others whose jobs require them to pay more attention to fixing broken things than to celebrating things that work well.

This glass-half-empty, perfectionist habit can be demoralizing to people who do a lot of work on a project and then hear nothing but negative feedback. It can also be demoralizing to people giving that negative feedback, because it’s easy for them get unhappy about relatively small faults.

So what I often do when helping teams navigate disagreement is to first identify where there *is* agreement and to write down those points of agreement before moving on to the (often small) subset of disagreements. Doing this has a few advantages:

• It stops people from rejecting a large body of work over a few fixable faults.

• It can jolt people out of a negative frame of mind, making subsequent discussions about remaining disagreements more collaborative. And it can build confidence on the team that a solution is within reach, because the disagreement is only a small part of a much larger pool of agreement.

• It suggests opportunities for compromise or synthesis by highlighting how relatively small the disagreement is. For example, imagine a mobile app with 10 screens, 9 of which are agreed-upon and one which evokes lots of disagreement. If you spend all your time arguing about #10, then it’s harder to get support for compromises like A/B testing two versions of that one screen.

• Some people have trouble taking yes for an answer; they’ll keep nitpicking settled points long after everyone else has already agreed. Writing down points of agreement is a convenient signal that it’s time to move on to the next topic, and if the same topics come up again, you can point back to your list to remind everyone about what’s already settled. It helps calm the trolls!

Make disagreement-resolving meetings boring

I’ve had a lot of success by making resolving disagreement as boring and predictable as possible: more like checking off a shopping list than arguing about something important. The goal is to turn down the emotional temperature and encourage quick resolutions, and nothing does that better than being dull!

So when I call a meeting to resolve disagreements, I’ll typically share my screen and open a document with two sets of bullet points with headings “To Resolve” (usually prepared in advance) and “Decisions”. When I find an area of agreement:

• I’ll say: “It sounds like we agree on ________. Does anyone disagree? [Pause, wait 2-3 seconds.] Great, let’s move onto the next topic.”

• I’ll delete that bullet from To Resolve, type a short bullet to append to Decisions, and ask “Does this match what we just agreed on? [Pause, wait 2-3 seconds.] Great, let’s move on.”

• If anyone mentions the same thing again, I’ll say “We previously agreed that we’d resolve _____ by doing _____. Do you have new info that would cause us to re-open that decision? [Pause, wait 2-3 seconds.] Great, let’s move on.”

This can get repetitive and boring, and that’s the goal: a monotonous walk through bullet points to put attendees in the right frame of mind to unemotionally solve problems and move on.

Vote early and often

Companies are not a democracy. But when the number of opinion-havers in a meeting exceeds 3-4, I’ve found that informal, non-binding voting can be a great way to speed up resolving disagreement.

Assume there’s 3 options that have been presented. You can ask for a quick show of hands for an in-person meeting. But I’ve found it’s actually easier and faster to do voting in writing, usually in shared meeting notes. Here’s one way to do it:

• First, list the options and number them

• Then everyone types a line in the (shared doc) meeting notes to rank the options in order of their preference, and distinguishing the options that they absolutely are not OK with vs. options that they don’t love but can live with. Optionally they can show notes about why they voted that way.

It could look like this:

Option 1: Show a modal dialog
Option 2: Make a new page
Option 3: Show AI recommendation, with “custom” button

JG: 2 (clearest UX) > 1 >> 3 (too costly)
PC: 1 > 2, 3
SM: 1, 2 >> 3 (too much technical risk)
KN: 3, 1 > 2

Given the votes above, it’s clear that option 1 is OK with everyone, which might not have been clear if you hadn’t written it all down.

Often, as in this example above, there’s one option that rises to the top: where some people love, no one detests, and others are OK with. This can be a quick resolution.

Of course, sometimes the consensus answer isn’t the best one. As a PM you sometimes need to be sometimes willing to fight for the right answer even when the tide is against you. Sometimes a lowest-common-denominator solution is unacceptable. But in my experience those times are rare; most of the time a fast, good-enough resolution is better.

Lose gracefully

No one likes a sore loser. Also, being branded as a sore loser makes it even harder to prevail next time.

If a decision doesn’t go your way, the best thing you can do to improve your chance of winning the next argument is to disagree and commit: accept the decision as valid and to do your best to support it. Focus on the future. Don’t whine about the past.

On the other hand, if you visibly have trouble accepting a decision, it will hurt your standing among your teammates and make it harder to gain support in future decisionmaking.

For example, years ago I joined a startup where a senior executive on the corporate finance team frequently complained about the company’s pricing model. Being new to the company, I assumed this was a recent change and he was still adjusting to it. It turned out that the change was over a year old! He just couldn’t let it go. The decision wasn’t going to be reversed, so by continuing to complain this executive achieved nothing other than making himself look less effective. Why remind your co-workers about an old fight that you lost?

Don’t be a sore winner either

Be chill if your favored opinion is selected. Never gloat! Everyone knows you got what you wanted, so reminding everyone will embitter folks who were on the other side.

Instead, if you downplay the outcome (and your role in it), then it’s a good way to repair the interpersonal rift that can happen when you get your way and others don’t.

A good way to do this is to de-personalize ideas. For example, say “If we’re going with this UX, is it something that Joe can start on next week?” instead of saying “Now that we’re going with my UX idea, could we assign Joe to work on it next week?” Everyone knows it’s your idea; there’s no need to rub it in.

Another good idea is to credit other people and elide yourself. For example: say “I’m glad we’re going with the Support team’s suggestion, because it matches what we heard from our SMB customers” instead of “I’m happy that this idea that Support and I came up with seems to align with SMB feedback”.

Never say “I told you so”

The advice above is especially true when a decision you opposed turned out to be a horrible failure.

Resist the urge to say “I told you so”! Everyone knows your original position, and they will appreciate your magnanimity in not rubbing their face in how wrong they were.

The only semi-exception to “don’t say I told you so” is when a past failure is helpful evidence when making a different decision. This works best if you don’t mention your role in that previous decision. For example, imagine if, over your objections, your CEO pushed your team to ship a big feature on Friday, and the launch was a disaster. The next time she’s asking you to do the same thing, consider saying something like: “Remember last quarter when we shipped a big feature on Friday, the entire team ended up working all weekend to fix it, and our Eng lead threatened to quit if we did it again? I think we risk of repeating that here.”

Don’t fight if you can’t win

Many years ago before remote work was commonplace, I was the only remote employee on my team. In meetings, I quickly noticed that it was nearly impossible to convince people when I was a disembodied voice on a speakerphone. Even if I had a powerful argument and strong evidence, the voice on the phone usually lost.

It’s tempting to let everyone know how unhappy you are with a group’s consensus or a leader’s decision, but in my experience this is ineffective, because the room will tune you out.

So I learned to sense whether the room was open to my idea or not. If “not” I usually quickly conceded or simply kept quiet. Then I’d wait for a more favorable opportunity to discuss it, for example during my trips to HQ or in 1:1s.

The point is this: if you know you’re going to lose an argument, then it’s usually better not to fight at all. I apply this lesson frequently, even when I’m not a voice on the phone.

Note that “don’t fight” doesn’t mean “don’t disagree”. You don’t have to be a pushover. There’s nothing wrong with presenting dissenting opinions in an even-handed way. Just avoid putting emotion and personal credibility into arguments where you’re unlikely to prevail. Save your political capital for times where it really matters.

Be fair; don’t be sneaky

It’s never OK to win arguments under-handedly. Examples of sneaky behaviors to avoid:

• Waiting to make a decision until the main proponent of the opposing view is out of the office

• Claiming that other people support your idea more strongly than they really do

• Massaging data to amplify your position or hiding contradictory evidence

• Convincing a senior manager to decide in your favor without giving the opposing side a chance to present their case

• Back-channeling to colleagues to convince them to support your idea “as a personal favor” instead of on the merits

It’s OK to put a thumb on the scale in your own favor. It’s not OK to put your whole arm on the scale! The other side will find out and will disrespect you. It’s not worth it. Also, doing underhanded stuff feels icky. Finally, what you should want is for the best ideas to win out. If you have to cheat, then maybe, just maybe, your idea isn’t the best?

“Pre-meet” to ensure high-pressure meetings go your way

If an important decision is coming up in a high-pressure meeting (like an executive-team review), it’s usually smart to meet individually with the participants ahead of time to gauge their opinions. If they have objections to your plan, then you can better understand their concerns (which is much harder to do in a large meeting) and you’ll have time to make changes to your plan to reduce or eliminate those objections.

Your goal should be for the big meeting to be a rubber stamp on what you’ve already worked out 1:1.

Note that this is *not* a violation of the “don’t be sneaky” rule above. Your role is not (only!) to convince people of your position, but rather to have a low-pressure way to build support the honest way: by hearing others’ concerns and feedback and addressing them before the high-pressure meeting goes awry.

This advice doesn’t only apply to high-profile decisionmakers. It’s also good to give peers and juniors a heads-up about an upcoming big decision, because they might be too intimidated to share their feedback with influential managers in the room. Also, if you think they might be surprised or upset at the likely decision, it will really help their morale (and increase their trust in you!) if you give them a low-pressure venue to discuss it beforehand.

Concede small disagreements; only fight for really important things

Reciprocity is central to human group psychology. If one person is perceived to always get their way, everyone else will get resentful. The same psychology works in reverse: if you are generous to someone else, they are more likely to be generous to you later.

For these reasons, I try to intentionally concede as many low-priority disagreements as possible, especially if someone else is strongly in favor of another position. This helps me build a reputation as a team player who’s flexible, reasonable, and generous. So when something really important to me is on the table, and I decide to forcefully push for my position, then I’ll be able to draw on the social capital that I banked by graciously conceding all those other previous times.

I’ve found that this approach works best if you figure out ahead of time what your top priorities are, and you let others know what they are. For example: “I care a lot about A, B, and C, but I’m flexible about almost everything else.” If your teammates respect you and value your agreement, they’ll often work hard to accommodate your “red lines” because of your track record of respecting theirs.

Even when you are clear—to yourself and others—about your top priorities, it helps to scope those priorities to be as narrow as possible. An example from my open-source work for the JavaScript standards committee: after adding a new time-zone-aware API called ZonedDateTime, I worried that our existing unaware-of-time-zones DateTime API would be a source of Daylight Saving Time bugs. So I pushed to rename DateTime to a longer name that wouldn’t seem like the default choice for novices. I told the team that renaming DateTime was a “red line” for me, but I was OK with almost any other longer name. Being flexible made it more likely that my narrowly-scoped priority would be satisfied. Which it was! (The final name was PlainDateTime.)

Sometimes, delay decisions until circumstances are more favorable

If you don’t think you can convince people of your opinion then it may make sense to defer the decision until you have time to think through the options and consult with others. This might be because you don’t have enough evidence or arguments worked out, or because you don’t have enough allies in the room for your opinion to carry the day.

Imagine you’ve scheduled a meeting for Thursday afternoon to hash out a difficult decision. On Wednesday night, you get a text message from a senior colleague—who was a key supporter of your position—saying that they can’t make it. What do you do?

My advice: postpone the meeting if you can. The same advice holds more generally: if you haven’t convinced skeptical stakeholders, then postpone the decision for a while to see if you can win them over. This is especially effective if you’ve followed my advice above to wait to publicly state your opinion until you’ve heard from others.

An example of this strategy literally saving the world is in Thirteen Days, a movie about the Cuban Missile Crisis in the early 1960s which was the closest the world ever came to nuclear war. I think every Product Manager should see this movie!

The film’s pivotal scene is a meeting where military leaders try to push President Kennedy into launching nuclear weapons in response to Soviet aggression. JFK knew that telling the generals “no” might risk a military coup, so instead he thanks them for their input and ends the meeting, promising to come back with a decision soon. This buys JFK time to figure out a peaceful resolution.

Summary: better decisions > winning arguments

Sadly for your ego, but probably better for humanity, the fate of the world isn’t depending on your ability to resolve disagreements at work. But if you follow the advice above, you’ll have a better chance of leading your colleagues into better decisions with less drama and strife.

The more you can see yourself as a catalyst of good decisions rather than a crusader for your version of the truth, the better everything will work out for you and your company.

Happy decisionmaking!

Roadmaps are a weird obsession in Product world. Every PM job description includes “create and maintain roadmaps”. Every PM “influencer” reverently talks about roadmaps as the crown jewels of Product work. And junior PMs seem to be more intimidated by building roadmaps than anything else.

Don’t worry, making a roadmap is usually easier than you think! I’ll try to take the mystery out of building a product roadmap for a B2B SaaS startup.

In this post I’ll share a step-by-step process that has worked for me and teams I’ve worked with, focusing on my last two PM leadership roles: Head of Product at UpCodes (SaaS compliance tools for the construction industry) and VP Product at Cantaloupe (SaaS predictive analytics and payment solutions for the vending industry). In my side gig as a PM mentor and consultant, I’ve also helped other PMs use the same process, with success.

What’s a roadmap?

The first step of roadmapping is to agree on what a roadmap is! Here’s my preferred definition:

A product roadmap is a prioritized, usually categorized, and periodically revised list of 10-30 things that your team is going to work on over the next 1-2 years.

Here’s more detail about each part of that definition.

• Prioritized. Your roadmap describes the order that your team is expected to work on and ship each item on the roadmap. It forces you to decide which things are more urgent and/or important.

• Usually categorized. Most B2B companies work in parallel on multiple business goals. For example, at UpCodes we had a parallel focus on growing self-service signups via Product-Lead Growth (Goal #1) as well as building enterprise-class tools for Building-Code Knowledge Management for the construction industry (Goal #2). Just like your business has different goals, your roadmap will have features and products that promote those goals. And when it comes time to prioritize features, you’ll usually want to prioritize them in regard to specific goals. For example, some features will help one goal but not others.

• Periodically revised. Roadmaps are living documents. You don’t want to change them every week or it will confuse everyone. But you should plan to update them as things change: new learnings about your market, opportunities you learn from customers or your own team, competitive threats, and so on. It’s helpful for your team if this update cadence is predictable, like minor quarterly updates, major updates every 6 or 12 months.

• 10-30 things. Your roadmap should be short enough to be listed on a sheet of paper or viewable on a single screen. It should be short enough to share with a trusted customer and get their quick feedback in a 30-60 minute call. It should be a list you can eventually turn into a slide, or a marketing page, or a white paper. None of those work if it’s too long, so you’ll need to coalesce and uplevel features into groups. The process of coalescing is helpful in itself, because it gets your team to see patterns representing customer needs beyond small features. Any longer and it’s a backlog, which requires a very different process to manage.

• 1-2 years. A roadmap is a medium-term document. It’s not about this week or next week’s sprint or the next release. And it’s not your 10-year plan for industry domination. Instead, it’s a preview of what your team will do in the medium term, so that your sales and marketing teams know what’s coming, so that your CEO can tell board members and trusted customers what to expect, so that your engineering colleagues can optimize hiring, and so that your company overall can stay excited about the future.

Building & maintaining the roadmap, step-by-step

Over the last 10 years I’ve built roadmaps for a few different B2B SaaS startups, and I’ve been keeping notes about what worked well. Here’s my notes, turned into a step-by-step list for how to build a roadmap within your first few months on the job.

1. Spend lots of time with customers to understand their needs firsthand.

   1. Talking with team members, lurking on public Slack or Discord channels, etc. are also good ways to get this info, although especially for enterprise customers you really need to go talk with them 1:1, ideally visiting in person.

   2. Learning from customers must happen in parallel to the rest of this list below. Don’t wait!

2. Talk with the team to write down the current state: what’s being worked on, and what’s already promised to customers in the near future. This is necessarily the start of the roadmap.

3. Talk with the team to document their promising ideas for the future. Not minor features but bigger investments that will move the needle on growth, competitive, etc. No judgement is required yet; just write stuff down.

   1. When you’re new, you won’t have much to add here, but as you get more familiar with customers you’ll be able to add your own ideas. But initially, plan to lean on your team. Luckily, few teams have a shortage of good feature ideas!

4. Combine (2) and (3) into a coarse-grained list of current and possible investments.

   1. Coarse-grained means a list of 30-50 possible investments over the next 1-2 years. Note that this is longer than your eventual 10-30 item roadmap. That’s because you’re going to cut or merge a bunch of these 30-50 items! This is just a first pass.

   2. A longer list isn’t a roadmap, it’s a backlog. You must keep the list small enough for everyone to wrap their heads around it, to read it on one page, to show it to a (very trusted) customer to get feedback, etc.

   3. If the list is too long, coalesce and uplevel features into groups or themes. The process of coalescing is usually helpful too, because it helps the team see patterns that map to customer needs beyond single features.

5. With the founders and others, clarify product-related business goals for the company overall.

   1. You can often find these in your company’s annual updates to investors. Your CEO should know these by heart. It’s your job to translate CEO-speak into product goals.

   2. For example, at UpCodes our initial roadmap goals were “Accelerate signups via Product-Lead Growth” and “Build Knowledge Management Tools for Building Code Compliance”. Ensure that everyone understands and agrees that these are the right goals. If folks don’t agree, STOP! You can’t build a roadmap if folks don’t agree on why to build things. Work with your CEO to resolve this!

   3. It’s OK if product goals don’t map 1:1 to company business goals. Sometimes you may need to split, merge, or reword them to make sense in a Product context.

   4. If you have more than 3-4 product goals, that’s usually an indication of lack of focus. And it makes roadmapping more complicated. Try to coalesce them!

   5. Your goals may stay the same year to year, or they may change. As your company’s goals change, your product goals should change too!

   6. Pick short names or acronyms for each goal, because you’ll be saying them hundreds of times. Wordiness wastes time.

6. Put the list of possible investments from (4) into a spreadsheet, or your favorite spreadsheet-like tool, e.g. Coda. Then add columns:

   1. Cost: agree on a unit of measure with your engineering leaders, e.g. developer months, or story points divided by 100. Estimates can be really rough, and (important!) Eng doesn’t have to commit to these. This non-committment matters because most engineering leaders are justifiably wary of being blamed for unrealistic estimates. Your task is to ensure that the granularity is coarse enough that your Eng counterparts don’t have to put too much work into estimation, and that they trust you not to blame them if estimates are off.

   2. Business impact: I like T-shirt sizes (S, M, L, XL), but any metric that doesn’t pretend to be quantitatively accurate (like a revenue projection) is OK. I’ve seen numeric measures like 1-4 or 1-5 work well too. Because features usually apply to different business goals, there’s two basic ways to organize your spreadsheet. If most features apply to multiple goals, then create one impact column for each goal, planning to leave impact cells blank if a feature doesn’t apply to a particular goal. If features usually apply to only one goal, then put each goal in its own tab or separate set of rows.

7. Get the right group of folks (founders + PM + Eng leaders + Sales/Marketing/CSM leaders + other knowledgeable folks) into a room or Zoom. The objective: assign guesstimates for cost and impact cells for each item in the roadmap spreadsheet.

   1. These meetings tend to work better as 2-ish-hour marathons, not half-hour chunks spread across days or weeks, because it takes 15+ minutes for people to get in the groove and move faster through the list. Also, context matters, and if you split into too many meetings then you risk having different attendees each time. Think of it more like a mini-offsite, not a regular meeting. Have short breaks as needed. If in person, order food!

   2. In addition to the main goal of assigning cost and impact, another important outcome is building a shared understanding on the team of what each thing actually is. This alignment is important when it’s time to rank the list.

   3. You’ll end up merging/splitting/adding items as folks discuss and clarify each item. This is good; don’t fight changes! Your role is to help the room coalesce on a shared understanding, not to dictate the outcome.

   4. Another likely result will be a consensus decision to cut some existing or long-planned features that everyone collectively realizes won’t be valuable enough. If everyone wants to cut something but some curmudgeon wants to retain it, that’s OK. It’ll get shoved down to the bottom later without the drama of cutting it now.

   5. You’ll likely need 2+ of these meetings to get through the list. I’ve found that people usually get really tired around the two-hour mark. If everyone is dragging, I’ll usually end the meeting and schedule a follow-up, because a tired and grumpy room won’t make good decisions.

8. Next comes stack-ranking, which is fun! Meet again with the same folks, with the goal of ranking your roadmap by bang-for-buck.

   1. This meeting will be shorter (90 mins is usually a good target) because the previous sessions have hopefully built a shared understanding on the team.

   2. To speed up the meeting, usually I’ll take an initial ranking guess using cost and benefit info. IMPORTANT: if you do this, share with the team that just because you took an initial stab at prioritization, the team should feel free to change it! Your role is facilitator, not dictator.

   3. “Bang for buck” ranking means that cheap things should be ranked ahead of costly work with the same impact. One way to estimate this: assign a point value to each impact measure (e.g. XL=10, L=5, M=3, S=1), multiply by the cost column(s), and use that result to sort the spreadsheet. But don’t be too finicky about ranking based on numbers. Your team’s collective judgement of which things are more important should trump any simple calculation.

   4. Go through the list one by one, asking “Should this one move up, down, or stay as-is?” What being decided is *not* whether something will ever ship, but simply what the team should work on first. This lowers the temperature.

   5. “Bang for buck” is inherently subjective, but it’s informed by cost and benefit assigned previously. The team overall usually has a good gut sense of which items belong above others, even if they can’t prove it quantitatively.

   6. It often makes sense to do a separate ranking for each business goal, esp. if the goals require largely disjoint work. Ranking in context to a particular goal is *much* easier than ranking across goals.

   7. Don’t waste time arguing. If there’s disagreement, ask what new information needs to be gathered to figure out its priority, park it off to the side, move on to the next item, and follow up offline.

   8. The lower you get in the list, the less time you should spend on each item because you aren’t going to work on those items for years (if ever).

   9. The output is a ranked list per business goal (or sometimes a global list).

9. Many teams stop at the step above. But having a stack-ranked roadmap without knowing when things will be delivered is hard, especially for Sales that needs to know when they can go after prospects who need specific features to buy, and for the CEO who will lose credibility with the board and investors if they can’t say when things are expected to ship. It’s better to take your stack-ranked roadmap and map it to the calendar. To do this, first you need to project the capacity of your team to build new features. Once you know that, then you can help the founders and other execs decide how to allocate that capacity across time.

   1. The first step is to decide what portion of your new-feature capacity you want to spend on each business goal of your company. I find quarters to be a good granularity. For example, at UpCodes in Q3 ’22 we wanted to spend 75% of new-feature capacity on our PLG (product-led growth) goal and 25% on Knowledge Management, and wanted to even that out to 50/50 in later quarters.

   2. New features aren’t the only thing your team works on. You’ll also want to allocate a percentage for “customer success”: small fixes and enhancements that make current customers happy but don’t move the needle on strategic goals. 10%-20% is usually a good target. You’ll also need a percentage for “tech budget”: retiring tech debt, tools upgrades, refactoring, etc. 10%-20% is usually a good target, although for startups with lots of tech debt this may be higher.

   3. The result is another spreadsheet tab, where one axis is time (e.g. quarters) and the other axis is the percentage of capacity you want to spend on each business goal, plus “other” items like customer success and tech budget.

10. Now you need to know the total capacity of your team in each quarter. Work with engineering leaders to roughly estimate total team capacity, on a quarter by quarter basis, using any metric that Eng prefers: story points, months, whatever. Something quantifiable, and translatable to the cost units from your roadmap.

    1. Make sure to include expected capacity increases from hiring, onboarding, etc.

    2. It may be appropriate to model a few possibilities, e.g. flat hiring vs. accelerated hiring.

    3. It may be that Eng has never done capacity planning like this. If so, see what you can estimate. It doesn’t need to be perfect.

11. Multiply (9) by (10) to get per-business-goal capacity for each quarter, after deducting customer success and tech budget allocations.

12. Now take the per-goal, ranked list of investments from (8) and start assigning them to quarters until you run out of capacity, then move to the next quarter, and so on.

13. What happens now is a brutal reality check when everyone is horrified at how little of the roadmap can actually get done in each quarter. Once everyone gets over the shock, you’ll want to collaboratively revise the roadmap and start cutting things or rearranging priorities. This often happens at every step above too, but it *always* happens as soon as dates are attached and calendar reality sets in. The result is much less ambitious…but much more realistic.

    1. A common response to this reality check is for teams to realize that something more fundamental needs to change, e.g. planning more fundraising, cutting big parts of corporate strategy to focus on core needs, etc. This is good! Bringing unrealistic hopes down to earth is part of PM’s job.

    2. You may be asked to build a few “what if” versions of the roadmap, e.g. what if we get an extra $10M of funding next quarter? Work with your Eng counterparts to translate those possible changes into capacity numbers, and rinse and repeat the steps above.

14. Congratulations, now you have a draft roadmap! Communicate the results out to the wider team.

    1. Be transparent about the process, goals, and why things ended up like they did. The more you de-mystify the process, the less FOMO and griping you’ll hear from people who weren’t in the meetings.

    2. Ask for feedback, and adjust in response to inevitable mistakes.

    3. Publish the roadmap in an internally-public place, and invite async feedback.

    4. Review it in an all-hands or whatever convenient non-async venue the company has. Encourage feedback.

    5. Be humble about expected changes, slips, etc. and help team to understand the inherent uncertainty and guaranteed changes that will ensue. Don’t lose credibility by being too certain about uncertain outcomes.

15. Rinse and repeat. Generally I’ve found that a good cadence is:

    1. Every quarter, adjust priorities and target quarters for everything on the roadmap. Publicize any changes (and explain why) so no one is surprised.

    2. Every year or so (maybe every 6 months in earlier stages), GOTO 1 and fully reassess the roadmap in light of market changes, new business goals, competition, etc.

    3. An important part of updating the roadmap is improving the accuracy of estimations of completed features and capacity estimates for completed quarters. If they’re way off, then work with your Eng colleagues to improve the accuracy of future estimates.

16. For the first year or two, *everyone* will probably want to be involved in building the roadmap.

    1. This will make your first few meetings large and chaotic while everyone figures out the process and their place in it. And you’ll get a lot of feedback from the team, some of it randomizing. This is OK. Roll with it. Roadmapping, especially at first, is often a weird combo of business strategy and corporate group therapy.

    2. But if people are comfortable that the process is OK and the output matches what they think is good for the business, then usually within 6-24 months most people get bored and they’ll start trusting that the right thing will happen even if they weren’t sitting in all the meetings. By Year 3-4, it’ll probably be just you, other PMs, Eng and Design leaders, hopefully the CEO, and token representative from Sales, Marketing, Support, and Customer Success. When most of your colleagues think of roadmapping as a boring and predictable process, you’ll know you’ve succeeded.

17. Nothing of above should be set in stone. The best process is a process that the team likes and that produces a good outcome. If any of above isn’t working, then change it! Be flexible.

Building your first roadmap (getting to Step 14) usually takes about two months. Much of that will be delays wrangling calendars for the group meetings, and follow-ups and research needed to resolve open issues and contentious items.

Caveat: big companies build roadmaps differently

I’ve seen the process above work well in smaller startups, meaning <100 employees, <$20M in revenue. It also works well at the team level in a larger company.

Where it won’t work is across teams in a big company, where executives are jockeying for resources and complex personal and strategic dynamics are in play. It’s not realistic to expect 10 teams’ general managers to sit in the same room and come to a consensus agreement that, for example, 2 of those teams shouldn’t exist. The myopic motivations of each team are too strong for solid company-wide prioritization to happen without the CEO forcing it to happen. You’ll need a different process than what’s detailed in this post.

Caveat: a roadmap won’t fix a broken company

I mentioned above that roadmapping can sometimes feel like corporate group therapy. It can expose and help to resolve misalignment and misunderstandings among your colleagues, and can help your team commit to shared goals and priorities even when not everyone was in alignment when the process started.

But PMs moonlighting as amateur corporate group therapists only works if your startup is fairly healthy to start with, meaning:

• The CEO, co-founders, and executive team mostly agree about the company’s business goals and the high-level strategy to achieve those goals. Roadmapping can refine and improve a business strategy, but it can’t create a strategy from scratch.

• People in your company are mature enough to know how to compromise, and how to resolve disagreements using evidence and/or consensus, with the CEO acting as tiebreaker or veto-er when needed. And when decisions are made, they’re not forever re-litigated.

• Your colleagues are not delusional; they can adjust to realities of customer demand, investor challenges, engineering capacity, and calendar time.

• Interpersonal dynamics are healthy enough that getting folks in a room together won’t devolve into a shouting match.

Your startup doesn’t need to be perfect to make a good roadmap. All startups are dysfunctional in their own special way. But there’s a difference between moderate misalignment and personality quirks (which roadmapping can accommodate) vs. more serious problems like founders at war with each other, delusional executives, or toxic personalities that derail progress.

If you don’t have a baseline level of teamwork, then you don’t just have a roadmap problem. You also have a more fundamental HR problem that the CEO (and perhaps the board) will need to resolve, and you may need to start polishing your resume. Fixing a broken company is way beyond the scope of this post!

What do you want to hear more about?

I could write a whole post about any of the 17 bullet points above, but I wanted to start with an intentionally-brief overview.

What do you want to learn more about? What parts are unclear or need more explanation? Let me know in comments here on this post, or hit me up on Threads or Twitter.

Subscribe now

Why won’t they just do what I want?

Every PM, every people manager, and every company founder asks themself the same question: “Why won’t people just do what I ask them to do?” If you have a senior job role, then other people should just magically listen to you and follow your requests. Right?

Sadly, this isn’t true. As every parent and manager painfully learns, it’s really hard to get other humans to do what you want. You don’t automatically get obedience along with a senior job title. Nor, in a professional environment, do you really want obedience. You want better results!

Effectively crafting and delivering feedback—and ensuring the best results from that feedback—are skills that must be learned. Hence this post.

What is feedback?

Last year I published How to Avoid Building Custom Features for One SaaS Customer, a post about effectively managing external customer feedback in a SaaS startup.

Lately I’ve been thinking about the other half of the feedback puzzle: managing *internal* feedback sent among colleagues. For example:

• When working with other PMs (either as a manager or peer) I’ll send feedback on their work, and I encourage them to do likewise for my features.

• When working with designers, I’ll typically work collaboratively with lots of bidirectional feedback back and forth throughout the design cycle.

• I like to send feedback to engineers on early iterations of new features, so that I can catch issues early and help identify opportunities to save labor before code is fully locked down.

• As a member of a startup’s management team, I’ll typically send feedback on company-wide initiatives and goals.

• I usually collaborate closely with marketing teams, so I’m often sending feedback on large marketing projects, especially when they intersect with product features.

• When working on features and plans myself, I like to get lots of internal feedback, not just from the usual suspects like execs and other PMs, but also from customer experts in Sales, CSM, Support, and others that have first-hand experience with our customers and industry.

This post is about making this kind of internal feedback successful, with a focus on improving the feedback you send to your colleagues. Many of the tips also focus on improving your ability to facilitate and coalesce the feedback of others across a team.

Even though this post focuses on PMs and product feedback, almost all the tips below apply to almost anyone giving feedback about almost anything. In particular, this post may be helpful for new managers and founders who want to spend less time and effort getting their teams to follow their requests.

Note this post is about *sending* feedback and managing the feedback process. Effectively *receiving and responding to* feedback from managers or other colleagues is also a pain point for many PMs, but this essay is already pretty long. So I’ll have to save “How to handle incoming internal feedback effectively” as a topic for a future post.

Giving good feedback: a cheat sheet

I’ll dig into more detail about each of these, but here’s a quick summary:

• Focus on improving this project AND improving the team

• Focus on customer needs, not your opinions

• Explain the “why” behind your feedback, with evidence and/or explanation

• Ask more questions!

• Prioritize your feedback

• Compliment before complaining

• Communicate problems, but avoid dictating solutions

• Tie low-level feedback to high-level goals

• Proactively and cheerfully admit when you were wrong

• Don’t gloat or say “I told you so” when you were right

• Build on the ideas of others

• Don’t expect all feedback to be followed

• Do feedback async, and (internally) in public

• Keep feedback short

• Feedback’s purpose is a better product, not you being right

Focus on improving this project AND improving the team

Giving feedback has a dual purpose:

1. Improving the particular thing you’re giving feedback about, like a proposed feature or a business plan

2. Improving your team’s ability to deliver great work in the future

Great feedback achieves both of these goals. But feedback-givers often omit the second one; they focus on improving today’s work, and forget about long-term team success.

This won’t be the last project that your colleagues will be working on, so you should always be thinking how you can help them get better and how you can improve your relationship with them.

One of my favorite managers, Quentin Clark (ex-CTO of Dropbox, now a VC at General Catalyst) told me a profound story about shipping his first huge project in tech. Quentin at the time was a hard-driving manager who was known for pushing his team to deliver great results. After he successfully shipped a big release, his VP pulled him aside for a chat. “Congratulations, you drove the team to ship a good product. But will they want to work with you to ship the *next* product?” Then he stopped talking, and let Quentin absorb the lesson: that successful management is not just about today’s results, but also it’s about preparing for the future.

The sections below outline some specific feedback tips—illustrated by examples from my own experience leading PM at B2B startups—for balancing both goals: ensuring that the current project succeeds while also growing the team’s skills and cementing your relationship with them.

Focus on customer needs, not your opinions

A risk when giving feedback is that your colleagues will see your feedback as *your* feedback: your individual opinions. This is bad, because how your team feels about you, personally and professionally, will profoundly influence whether they follow your advice. You don’t want people to do what you recommend because they like you, or because you have a senior title. You only want them to follow your advice because it’s good advice! And of course you don’t want your advice to be ignored if you’re unpopular.

A good way to de-personalize feedback is to bring customers into the mix: to make it clear that you’re channeling customer needs, not your own preferences. There’s a few benefits to this:

• Obviously, it helps keep the team focused on the opinions that matter most: the people who buy and use your product!

• It also helps train your team to separate their own opinions from what customers want, because often the PM is—or should be!—the person on the team whose opinions are closest to the customer. Others (especially engineers) often have really different preferences from normal users, so modeling “You are not the customer” for them is often necessary.

• Finally, I’ve found that de-personalizing feedback makes discussions (and especially resolving disagreements) smoother and more efficient, because you’re not directly rewarding or challenging each other’s opinions. Instead, it’s more like a science problem happening to someone else, which lets everyone evaluate it with less emotion involved.

Here’s a few examples from my own experience showing how you can de-personalize your feedback:

• “Font sizes are too small” ⇒ “Many of our customers are in their 40s and 50s, and folks that age often have trouble reading small text. Should we consider making text a bit larger here?”

• “This feature seems really similar to our existing feature X; why can’t we just add it to that page?” ⇒ “In our last conversation with customer A, they complained that there were too many ways to accomplish things in our app. This new feature seems to be pretty similar to feature X… maybe we should try to merge them?”

• “Customization never works at scale” ⇒ “Personally, I love to customize my apps as soon as I install them. But I’m probably unusual, because when I visit with our users, I’ve almost never seen them use our existing customization points. What’s different about this new customization feature that will lead to a different outcome?”

• “Dark mode isn’t a priority” ⇒ “I know it’s weird because you and I and most of the people we work with use Dark Mode, but when I’m out visiting with customers I’ve yet to see any of them using Dark Mode on their OS. I’m not opposed to adding Dark Mode, but we’ll need more signal that customers will use it before I’d recommend building it.”

Explain the “why” behind your feedback, with evidence and/or explanation

It’s not enough to tell people what you (or customers) like and what you don’t. You also need to tell them the *why* behind those opinions. This is important because if the team doesn’t understand the whys behind your preferences, then they won’t be able to apply that reasoning to other problems in the future. They’ll never learn.

A good rule of thumb is to make it your default behavior to attach “because…” to every major piece of feedback. Make it a habit.

There will be cases where the why is self-evident and you can omit the why: typos, visual misalignment, etc. But making “because…” a habit forces you to think every time: is this really so obvious? Often what’s obvious to you, an experienced PM, may not be obvious to a junior engineer, designer, or marketer!

Here’s some examples (pulled from my own experience) of explaining why:

• “I’d suggest removing the ‘Add to Favorites’ feature in this release because it’s not required to ship 1.0 and we’re already overloaded on feature work this quarter. Can we add it in a follow-up release?”

• “I worry that the proposed navigation buttons won’t be discoverable enough because their background colors are too similar to the overall background of the nav bar. Have you tried other colors?”

• “You mentioned concerns about the length of the signup form, but I’m not too worried about it because we’ve tested similar changes repeatedly and found that, surprisingly, our audience can handle up to 5 questions without hurting signup rates.”

• “I think we can safely defer Dark Mode for a while, because according to last month’s usage data, only 3% of our users were using Dark Mode at the OS or browser level.”

Note that you don’t need statistically-significant, scientific data. It’s fine to share anecdotes, like this: “…because when I was at the industry conference this year, I kept asking users if they’d tried Feature X and not a single one said yes. So I think we need to do more work in the product to make that feature more discoverable.”

Even if your justifications are outdated or secondhand, it’s OK to share your opinions… just explain *why* you have those opinions. Like this: “10 years ago my team did a lot of usability research with menus in a web app, and I kept seeing that users in the lab were reluctant to read through menus longer than 5-7 items. Since then I’ve been really skeptical of long menus.”

Another benefit of explaining why is that it forces people to think about whether your “why” actually makes sense. This especially matters if you’re a senior person giving feedback to a junior team, because they might be inclined to just do what you tell them in the common case where they don’t have enough context and/or courage to tell you when your advice is bad.

By adding the why, you give them more information about your thinking which makes it easier for them to help you if you get it wrong. And even if you’re not wrong, having context might help them find optimizations or other improvements that you didn’t think of initially.

Ask more questions!

My biggest feedback hack is really simple: I ask lots of questions! Questions are a feedback superpower. Here’s a few examples of feedback that may work better as a question:

• “This design won’t work on mobile” ⇒ “How will this design behave on a mobile device?”

• “This page downloads 7MB of JavaScript before I can click anything!” ⇒ “Have you been able to test performance at 3G speeds?”

• “We shouldn’t spend so much of our roadmap on a segment that only accounts for 5% of revenue” ⇒ “I see that we’re spending most of our roadmap on Segment A. Are they projected to be much more revenue than last year?”

Here’s a few reasons why question-asking is such an effective practice.

Questions give the recipient an opportunity to look (and be!) smart and competent

Like most teenagers, my kids are required to do chores around the house. Nothing annoys them more than when I ask them to do their chores and they yell at me “Dad, I was just about do those chores!” They’re annoyed because I’ve robbed them of the feeling of being in control of their own work and demonstrating their competence by being proactive.

At work, similar dynamics are at play. If you’re giving feedback to someone who's planning to do something—but they haven’t gotten around to it yet—then asking questions is an invitation for them to tell you about their plans proactively without them (or you!) feeling like they’re just following your orders. For example, “What’s your plan for when the user is offline?” is an empowering invitation for someone to share their thinking about how to solve offline-user cases. “This document is missing a discussion of offline mode” or, even worse, “I think you should handle offline users by caching their documents” is needlessly disempowering and frustrating, especially if the recipient already has a plan for solving for offline users.

Questions help people save face when they screw up

Questions are a lower-pressure way to help people figure out when their plans have problems, and to recover from those problems while not embarrassing themselves.

Using the “offline users” case above, what if the feedback recipient had never even thought about offline users? If your questions are async (e.g. Slack, email, comments in a document or bug-tracker issue, etc.) then the recipient can take a few hours to come up with a good answer. They never have to admit that they didn’t think of the problem until you asked them. Especially for junior employees or folks from cultures where “losing face” is shameful, this can be a useful way for you to ensure that problems get fixed without the recipient being exposed as ignorant.

Of course, you should also encourage people to be self-aware and self-confident enough to admit that they didn’t think of the problem before you brought it up. But it’s best to let them do it, rather than you doing it for them!

Questions help you evaluate the recipient

If you tell someone what to do, you’ll never know if they were able to get to the same result (or, ideally, a better one!) without you coming up with the solution. If you ask questions, you’ll get clearer signal about their capabilities.

Questions force the recipient to think, not just follow your orders

Most people are busy. If you tell them what to do, many people will just do it without thinking too much about whether your advice is the best solution. Answering your questions requires people to think, which avoids mistakes and helps them learn more quickly than just blindly following orders.

Questions help the recipient explain their work

Many smart people often intuitively come up with good solutions without really knowing how they arrived at those solutions. Asking questions encourages those folks to slow down and explain their reasoning, which often helps them improve their thinking and also improves their ability to communicate with less-intuitive or more-skeptical colleagues.

Questions show that you’re interested, which builds morale

Questions are a signal that the opinions of others matter to you. When you’re asking other people to do hard work, it really helps to show that you care!

Prioritize your feedback

When you give lots of detailed feedback, it can be hard for busy people to know what parts of that feedback they need to act on first. They might end up spending 90% of their time on feedback you don’t care about very much, and might run out of time for the critical stuff.

So tell them what’s more important by explicitly declaring the priority of each part of your feedback!

One easy way to do this is to split your feedback into headings, e.g. “High Priority”, “Medium Priority”, “Low Priority”. Or “P1”, “P2”, “P3”. Ideally, you’ll be able to re-use an existing prioritization vocabulary that your team already understands. But in general, you probably want to use buckets like these:

• Your highest-priority bucket are things you really, really want to be included. If they’re not included, you expect the recipient to explain why not…and if you're letting them know that you may argue or escalate if you disagree with their response.

• Your medium-priority bucket are things you think should be included, but you accept that they may not make it in, especially if they are expensive or difficult.

• Your low-priority items are at the whim of the recipient, and it’s OK if they don’t make it in.

If you consistently label the priority of your feedback, then it makes it more likely that your top priorities will be taken care of, and it simplifies life for the recipient because they know what’s your minimum bar.

Compliment before complaining

A rookie feedback mistake is to focus on what’s wrong. It’s just as valuable to explain why something is good. This can help recipients align with your judgement in the future. It also works better from a human standpoint, as opposed to feedback that's only a reminder of where you’re screwing up.

This doesn’t mean to fake it. Rather, before delivering constructive feedback, you should step back and ask yourself “What’s good about this work?” and communicate that genuinely. Your team will benefit!

The most common reason I’ve heard for why people (esp. senior people) don’t give positive feedback is because they’re too busy. They just want to focus on what’s needed to fix. In my experience, this is short-sighted and inefficient. Having a grumpy team that’s de-motivated at work will quickly cost you much more time than taking a minute to think about—and then communicate—what’s good about their work.

Communicate problems, but avoid dictating solutions

Good feedback can help the recipient see and \understand the problems they need to solve. Sometimes they may have already seen those problems themselves. Sometimes not. Regardless, your information about which problems are important to solve is perhaps the most valuable part of your feedback.

For example, here's feedback that I once sent to one of the PMs on my team: “I like how you laid out this dashboard with paid features more prominent. That's smart. Hey, our median desktop user’s browser is only 960px high. Will they see enough without scrolling?” Note that even though (per advice above) I softened feedback with a question, I’m still clearly stating a problem to solve: users with small browsers may not see enough content.

It’s often best to stop there, without offering solutions to the problems you identified. Why?

• You may not have enough context to solve the problem in the best way.

• Especially if you’re senior, the team may be hesitant to solve the problem differently than you suggest, even if their solution is better.

• It’s disempowering for smart, competent people to be told how to solve a problem.

• To grow problem-solving ability, a team needs practice solving problems.

• You’re busy, and it’s faster to define problems than to solve them yourself.

Senior people often come up with high-quality solutions 5x+ faster than junior folks on the team. So it can be really hard to *not* offer solutions as a shortcut to help the team move faster and achieve better results.

But the more the team relies on you as their problem-solver, the harder it will be to scale problem-solving at your startup. Unless you want to solve everyone’s problems forever, you must help your team get better at solving them… themselves!

That doesn’t mean you need to ship crap, or to let your team fail. It just means that it’s usually smart to let the team take a first (and often second, third, etc.) crack at solving problems before you consider jumping in and saving the day.

Planning vs. executing

My theory (if you’ve seen neuroscience research supporting or refuting this, please let me know!) is that humans have distinct mental pathways for “planning” vs. “executing”.

When you’re in a planning mode, you’re carefully evaluating different options and thinking creatively about the right path to get to a solution. Your focus in this mode is about the quality of the solution.

In executing mode you’re working in a straight line towards the solution you’ve defined earlier. In executing mode your focus is purely on speed, which also makes it easy to quickly deliver…the wrong thing.

Normally, humans flip back and forth between the two modes. You’ll come up with a plan, then start executing on it, but often you’ll realize in the process of execution that the original plan had problems. Then you’ll shift modes again to change the plan—with better information now—and then switch back to executing the new plan.

But when an authoritative person at work is too proscriptive about the solution required, what I’ve seen happen is that people turn off the planning part of their brain. A few reasons:

• Mental energy conservation: “An authoritative person has already laid out how we’re supposed to do it, so I can confidently accept that it’s the right plan. Now I don’t have to waste time making it better.”

• Social pressure: “An authoritative person told me how to do it, so if I have concerns they may not be welcome. Worst case, it could hurt my standing at work.”

• Self-doubt: “An authoritative person came up with this idea, so what’s the chance that my idea is better?”

The solution: as a feedback-giver, you should leave space for your colleagues to feel (and be!) accountable for figuring out the solution on their own, without your feedback being so proscriptive that they don’t have to think about the solution.

Below are some challenges you can expect with this not-too-prescrptive feedback approach, and how you can react to those challenges.

I want to send my solution anyway!

Let’s assume, like many feedback-givers, you sometimes have good reason to disregard my advice above, and you just want to send your preferred solution. Here’s a few suggestions to make sending solutions work better for you and your team:

• Send the roughest solution possible. If you must suggest a solution, don’t send something that looks like a finished product. If it’s code, send pseudo-code. If it’s a visual design, send a rough sketch or, even better, describe your ideas in words. If it’s feedback on a slide deck, send them notes, not slides. It should feel to them that your contribution is *helpful ideas and suggestions*, not a finished product. This empowers the team to think of the solution as theirs that they made from the raw material you gave them, instead of *your* solution that they have to adopt as-is.

• Send multiple solution ideas. It’s often smart to send multiple ideas over to the team. This empowers them to pick and choose the best one(s), which helps them feel (and have) more ownership and accountability over the result.

• Sound more tentative than you feel. A trick I use whenever I share solutions is to wrap my suggestions in tentative language. For example, instead of “Please split the Account Management page into a separate Billing and Users page” I’ll often soften the feedback like this: “I was wondering, to solve the real estate problems we discussed earlier, do you think it’d work better if we split the Account Management page into a separate Billing and Users page?” This kind of tentative language gives the recipient more control and accountability because your language gives them more freedom to choose whether to accept your solution or not.

  • Note: this advice may not work as well if your communication style at work is already tentative, or if your colleagues already don’t take your ideas seriously when framed in tentative language. For example, if you’re an introverted, shy woman on a team of bros, then it might not help. But if you’re a pushy, loudmouth guy from New York like I am, then softening your language works really well!

• Be OK if they choose a different solution. Part of the reason to use tentative language is to help yourself be OK with the team picking a different solution from the one you had in mind. Especially if you’re a senior person giving feedback, it sends a powerful signal to the team if you give them the freedom to pick another solution.

In my experience, the last bullet point above is the most compelling reason to avoid suggesting solutions: coming up with your own solution makes it harder to appreciate others’ ideas! It’s human nature for solutions you came up with to seem familiar and obvious, just like a song played a few times can grow on you. Later, when you compare your proposed solution to solutions that others come up with, you’ll naturally give extra preference to your own. It’s easy to convince yourself that your own idea is the best, even if you really only like it because it’s familiar. This is especially true for problem spaces like visual design where success criteria are more subjective.

For this reason, and because it saves me time, I try to avoid dictating solutions to a team.

I didn’t send my solution, but the team came up with a solution that’s much worse than what I had in mind. Now what?

Just because you gave the team freedom to come up with a solution doesn’t mean they’ll always succeed! At this point, you have two options:

1. Give them more feedback, using the techniques described elsewhere in this post, to help them improve their solution.

2. Propose a solution of your own, using the suggestions above.

There’s no hard-and-fast rule about which option is best. Often I’ll go one more round of feedback before sending my solution over.

If I do send a solution, I try to fit into whatever framework and terminology the team has already come up with. That way, my suggested solution feels more like an extension or synthesis of theirs, rather than a repudiation.

Tie low-level feedback to high-level goals

PMs, especially senior PMs, often have a more holistic view than paper on other roles, like engineers or salespeople. So it’s important when giving feedback that you explain how your feedback fits into higher-level objectives of the company, especially objectives that may be less familiar to some people. A few examples:

• (in feedback to engineers) “Our goal for this year is to grow revenue in non-US markets, and we know that users in many international markets are much more weighted to mobile, compared to the US where most of our users are desktop. But when I loaded this new page on my phone, it was really slow to load. Could we look into that?”

• (in feedback to marketers) “I know that our SMB segment has always contributed the majority of our revenue, but our Enterprise business is growing three times as fast, and we know that different messages resonate with SMB vs. Enterprise. Is it worth having two separate versions of our monthly newsletter?”

• (in feedback to salespeople) “This customer seems like a good fit, but the custom features they’re looking for are going to be tough for our engineering team to deliver this quarter, given that Eng is busy finishing a big feature upgrade for our reporting dashboard. And many more deals are depending on that work. So I’d suggest putting this customer on hold for a while or seeing if we can close them without committing to their requests.”

In each case above, I’m sharing information from another part of the company that may not be widely known. This helps the recipient contextualize your feedback better.

Proactively and cheerfully admit when you were wrong

This one is an easy hack: when your feedback is proven wrong by later events or data, loudly admit it!

An example of this was when I was Head of Product at UpCodes. Our free product allowed users to view the building codes for every US state and many large cities. We decided to promote one of our paid features (“diagrams” that visually explained building codes) by injecting thumbnail images of each diagram in the middle of building code text that those diagrams explained.

One of the most senior people at the company was worried that free users might be frustrated by having prime real estate occupied by content they can’t access without paying. He was sensibly concerned that we’d piss off our future customers by making the free product more annoying. But we ended up testing shipping this feature despite those concerns, and in this case the gamble worked: the change ended up boosting paid signups by more than 50% without generating many user complaints.

Afterwards, he sent a public Slack message to the company, acknowledging that he was originally skeptical of the solution but that he was very happy to be proven wrong!

This was a really smart move on his part. Personally, it boosted my respect for him and made me more confident that he'd be fair in the future. It showed he was a team player, more interested in results and team success than his own ego. It made him look smarter because he was willing to change his mind in the face of new data. I try to follow his impressive example whenever I can.

Don’t gloat or say “I told you so” when you were right

On the other hand, when your feedback isn’t followed and bad things happen, it can be tempting to take a victory lap. Don’t do this. People already know you were right last time, and therefore will be more likely to listen to you next time…unless you try to rub their faces in it! Don’t do that.

When your feedback *is* followed, it’s just as important not to make a big deal of it. Let others take the credit. Especially if you're more senior, it's good to talk about the final solution as theirs, not yours. In a team, no one person is responsible for success, and the more you make others feel like they will win (socially, professionally, and financially) when they follow your feedback, the more likely they’ll be to follow it in the future!

Build on the ideas of others

Another trick to ensure your feedback is treated well is to think of feedback like a jazz band solo, which works best when you pick up and expand on the themes that others have started.

When giving feedback I’ll often try to name-drop other team members, like this:

• “I was concerned that we were hiding too much information from the user, but I really like Dan’s idea about having the information be hidden by default, but when you tap on the icon then it will expand down and show the extra info. How’d you feel about extending that with an ‘always-expand’ setting so users who like the extra detail won’t have to tap all the time?”

• “Molly’s mockup is my favorite so far; I like how it is easily readable both on desktop and mobile screens. Have we considered an intermediate setting for iPads?”

In both cases above, I’m building on the ideas of other team members instead of striking out on my own path. Part of this is because I really liked Dan’s or Molly’s ideas, but part of it is strategic: I’m encouraging a path towards consensus and agreement by enlisting and promoting the ideas of others, which in turn usually makes it easier for them to support the changes that I recommend.

Don’t expect all feedback to be followed

No matter how senior you are, if you expect the team to do 100% of what you ask them do to, then you’ll always be disappointed and the team will always be annoyed.

Instead, be prepared for some percentage of your feedback to be ignored, to be implemented poorly, and otherwise for the outcome to be worse than if you’d done the work yourself.

I learned this lesson early in my career from another one of my favorite managers, John Case, who’s now the CEO of Acumatica, a SaaS ERP company. He told me about handing off a big project to his Marketing lead, and then being disappointed in the final result. “I knew I could have done it better myself,” he told me, “But you always have to carefully choose where to dive in. In that case, doing it myself wasn’t nearly as valuable as helping out another part of the team that was struggling. It’s impossible to scale as a leader until you accept that not everything will happen exactly the way you want it. For all but the most critical things, you need to give good feedback and embrace ‘good enough’ results.” This was powerful advice that I’ve kept in mind ever since. Thanks John!

One more note: even though you can’t expect all your feedback to be followed, if you clearly prioritize your feedback (as discussed earlier in this post), then you’ll have a much better chance that at least your highest-priority feedback will be satisfied.

Feedback should be async and “internally public”

Early in my career I worked at a very large tech company where a lot of effort was spent on “exec reviews”: high-stress exercises where we’d prepare for weeks for a half-hour with some important senior person, who’d review our plans and give us immediate feedback that we’d then spend the next few weeks, months, or even years executing on.

That sucked. By relying on time-limited, high-stakes feedback sessions, so much nuance was lost, so many things were misunderstood, and so much time was wasted before, after, and during these reviews. It was profoundly inefficient. And this “review culture” ended up prioritizing PM skills and time around meetings and presentations, rather than on satisfying customer needs.

What I took from that experience was two learnings, both of which I’ve tried to apply since I started leading product teams at startups a decade ago:

First, feedback should ideally be asynchronous, so that people can send feedback, hear others’ responses, think about those responses, reply back, and gradually come to consensus (over days or sometimes even weeks) about the best path forward. I’ve found that a longer, async feedback cycle generates more thoughtful feedback, less wasted prep time, and a better end result. Async feedback also really helps teams that are geographically and/or chronologically distributed.

A challenge with async feedback is that it can be hard to wrangle everyone to actually give feedback without the forcing function of review meetings. So it can be helpful to set deadlines for the team to review, and you will probably have to harass important team members to get their feedback in. But this harassment work is much less wasteful than having the whole team work for a week to prepare for 30 minutes with a VP!

Second, feedback should be “internally public” instead of being limited to a few senior people in a conference room. I’ve been consistently impressed with the useful feedback contributed by junior colleagues, especially engineers but also including marketers, salespeople, support engineers, and CSMs.

Therefore, I like hosting feedback in Google Docs, GitHub issues, Figma files, or other multi-player environments where everyone is free to comment, regardless of their job title. I don’t have a favorite tool; instead I like to “meet teams where they are” using multi-player tools they’re already comfortable with.

I’ve also found that these kinds of public, written records are very useful for going back later (sometimes years later!) to understand why decisions were made.

Keep feedback short

Finally, remember that everyone is busy, so try to keep it as short as possible. Just don’t make it so brief that it’s ambiguous or confusing, because that wastes more time later.

Model good feedback-giving skills for others

After hearing these feedback-giving tips, you’re probably wondering: “But what about people who give *me* feedback? They don’t do any of these good things!”

Yes, one of the challenges of PM work is that everyone feels entitled to tell you, often in excruciating detail and without any evidence or explanation, what should and shouldn’t be in the product.

Over the long term, I’ve found that the best way to improve the quality of feedback you get from your colleagues—and to help your entire organization manage internal feedback better—is to lead by example and improve the feedback you send *to* your colleagues.

Conscientious or observant people will notice what you do, and will often try to emulate it, given that you’re supposed to be the Product expert. Others (executives, people on the autistic spectrum, people not from a tech background, etc.) might need more explicit encouragement, and it really helps if you’ve been modeling good practices so they don’t think you’re being hypocritical.

<plug shameless=”yes”>
Another way to improve feedback in your org: post a link to this essay in your company’s Slack. 😄
</plug>

Feedback’s purpose is a better product, not you being right

I’ll close this list with a reminder: the goal of product feedback is not to get other people to do what you want. The actual goal is to end up with a better product!

As a PM, you should in general be “more right” about product direction than other people on the team. If not, why do you have that job?

But when done correctly, product feedback should feel less like you telling people what do to, and more like being a facilitator who’s responsible for finding and coalescing the ideas of everyone (including your customers!) into the best possible product strategy and user experience. The more senior you get, the more it should feel like that.

In practice, PMs are often the source of more product ideas and more product feedback than anyone else on the team, partly because we are hired for product sense and because we spend lots of time with customers.

But it's fine if you didn’t come up with many ideas. As long as you extract, improve, synthesize, and prioritize good ideas from customers, execs, teammates, competitors, and others, then you can be a success. I’ve found it helpful to think of PMs as coaches and enablers rather than PM as “CEO of the Product” who dictate and others follow.

Bringing this “coach and enabler” mindset when you send product feedback will make you more successful, because others will see you as a champion for their best ideas. And it ensures that when you do have good product ideas of your own, then the team is more likely to listen.

Epilogue: “I shouldn’t have to water down my feedback to save peoples’ feelings!”

A concern I had writing this post: senior people reading it might think that I’m recommending watering down their feedback. Your instincts might tell you that “tough love” worked to help get you where you are today, and that the same approach should work for everyone…at least everyone who’s good at their job.

Senior people in a company do live in a “tough love” environment. They regularly receive blunt feedback from more-senior executives, from investors, from customers, and from random Twitter trolls. If you spend time in that kind of difficult environment every day, my advice in this post can seem wimpy and ineffective.

If this is you, then here’s another way to look at the techniques in this post: they let you deliver difficult feedback to people while maximizing the chance that that feedback will be adopted. These techniques may not *feel* as natural to you, but they’re more effective.

Here’s why: all people have psychological defense mechanisms that sometimes make it harder to listen to and act upon negative feedback. If your feedback triggers those defenses, then your feedback may be rejected. At a minimum, it won’t have as much impact.

The techniques in this post are like a stealth drone. They help your feedback avoid triggering the psychological defenses of the recipient. They let you deliver a “payload” of feedback with less interference along the way, and without collateral damage to other work, to morale, or to your relationships with the team.

This doesn’t mean you need to change *what* you say. It just means that if you change *how* you say it, then you’ll get better results.

This is hard. It can feel strange, like you’re not being true to yourself, or that you’re uncomfortably constraining yourself. It can feel slow. Awkward. I get it. Honestly, I felt the same way when I started practicing these techniques. But then I started seeing results: people were much more likely to do what I wanted them to do! This made all the extra effort worthwhile.

A big challenge for Product Managers is balancing strategy (“what should we do?”) with execution (“let’s get it done!”). Finding the right balance between the two is never easy. One seemingly-promising solution is to split the PM job into a strategy-only role of “Product Manager” and an execution-only role, often called Product Owner, Technical Product Manager, Program Manager, or Project Manager.

In B2B Product teams, this split is usually a bad idea. It costs money and morale. But worst of all, spreading the work around usually makes teams go slower, not faster as intended!

This post coalesces what I’ve seen—across more than a decade of managing B2B product teams in both startups and BigCos—of various challenges that come with splitting the PM role, and how to avoid those challenges.

Splitting PM: why it happens

In a SaaS startup, the typical reason why these roles are split goes like this:

• “Jimmy” on the Marketing (or Sales, Marketing, Support, etc.) team has lots of domain expertise and understands customer needs really well, but he’s disorganized and doesn’t like to sweat the details. He travels a lot so is often unavailable to answer questions. He also has limited tech experience and has no idea how tech products get built. And he’s always randomizing the developers so they dislike him.

• “Victor” is a junior PM with great organizational skills, good rapport with engineers, but isn’t very familiar with the market, isn’t plugged in with the Sales team, and isn’t comfortable presenting to or defending his decisions to management.

Naïve leaders might think that the right solution is to put Jimmy in charge of roadmap and product decisions, while Victor can focus on executing those decisions by working with engineers (and everyone else) to get the product shipped. Jimmy likes this because he can direct the product without getting sucked into the weeds. Victor likes it because he can stay in his comfort zone: working with engineers and focusing on “process”. Everyone wins, right?

Wrong. Building a tech product is not like plugging an address into Google Maps and blindly following directions for 500 miles. Building tech products is like a NASCAR race where the driver and the pit crew continually make hundreds of decisions—large and small—to make optimal use of scarce resources and to beat the competition. If you slow down your decisionmaking process or reduce your decisionmaking quality, then you’ll lose the race.

To make decisions well and quickly, you need one person who’s empowered to make decisions and who has context (business, technical, interpersonal) about why those decisions are and should be made. That person doesn’t need to have the job title “Product Manager”, but they do need to understand the business, understand how tech products are made, and to be consistently available to work with engineers and others to make decisions and tradeoffs. “Jimmy” never has the bandwidth nor inclination to do this. He’ll get bored!

Your best answer is to hire “full-stack” PMs who have both great business/product sense (“what should we build?”) and great execution chops (“how do we get it built quickly with the right level of quality?”).

But life isn’t perfect. Imagine you have a flaky Jimmy and a shy Victor on the team. How can you make it work? Here’s what I’ve done in the past in similar cases:

First, I’d send Victor and Jimmy on a road trip for a few weeks to visit customers. Jimmy’s job is to educate Victor about what the market needs. Victor’s job is to absorb knowledge from Jimmy and the customers they visit. The goal: Victor should be able to answer most questions without having to bug Jimmy, but also should learn which questions are complex enough to need Jimmy’s advice. If possible, engineers and designers should go with them—the more the merrier to learn about customers.

Then, when the team is back in the office, Jimmy, Victor, the lead Engineer, and other senior team members should lock themselves in a room for a day or two and hash out a draft roadmap. Given that they’ve all seen the same customers, firsthand, getting consensus is easier than you’d think.

After that, Victor should keep Jimmy closely in the loop, ideally with regular 1:1s so that they can discuss progress, solve problems, and ensure that Jimmy feels involved *without* having to directly bother the engineers. When it’s time to present progress to the management team, Victor should present but should pre-review with Jimmy so that Jimmy supports him publicly when the heat is on.

But on a day-to-day basis, the team should know that Victor is the go-to person for product decisions.

And if Victor can’t do this, then you probably need to recruit a “Caroline” who is capable of thinking about both business and execution at the same time.

Even great split PMs are inefficient

The story above is a typical case of roles being split because of skills gaps. But even if you put perfect people on both sides of a split PM role, there’s still an inherent inefficiency. It’s easy to see this graphically:

Going from a team of 3 to a team of 4 will *double* the number of interpersonal connections that must be managed! It also makes it harder to schedule meetings, makes team-wide ad-hoc chats less practical, makes it harder to get consensus quickly, increases the number of different opinions that must be addressed, increases the chance of misunderstandings, and so on.

The point is that human groups work faster and more efficiently if they’re composed of fewer individuals with a wider set of skills. It’s one reason why startups can move faster than BigCos.

This is why replacing one PM with two PM-like people will seldom speed things up.

In theory, you could arrange things like this:

This organization might solve the “number of relationships” problem, but it also means that neither of the Partial PMs have a full picture of what’s going on. One of them knows implementation status and has great synergy with engineers. The other understands the strategy but can’t make the day-to-day adjustments in that strategy based on what’s happening during implementation. This is also inefficient.

How to hire and support Full Stack PMs

It’s hard to find PMs who are both good at strategy and good at execution. Luckily, in a SaaS startup you only need a few PMs. For example, when I left Splunk a year before IPO, it was valued at several billion dollars and had fewer than 10 PMs. So be picky!

One thing I do when interviewing PMs is that I always ask to see multiple writing samples: one that’s more technical and focused on execution (like a spec or PRD that engineers read) and one that’s more business-focused: a product plan, roadmap, strategy doc, etc.

Then during interviews, I like to ask questions about both docs, and test the candidate’s understanding with follow-up questions about both high-level and low level concepts. If I don’t see comfort and competence in both areas, then I’ll usually pass.

Every candidate will be stronger in either strategy or execution. Nobody’s perfect! So I like to help newly-hired PMs gradually stretch themselves in their less-strong area. For example, I might assign a part of a strategic plan (like a mini-roadmap for one part of the product) to a new better-at-execution PM, or ask a strategy-comfortable PM to partner with a senior engineer on a complex feature.

Over time, people tend to gravitate to where they’re most comfortable. This can exacerbate an imbalance between strategy and execution. Therefore, I periodically check in to make sure that each PM hasn’t veered too far into either a strategy or execution focus, and I’ll help them find projects to get in balance.

Avoid the “strategy-only PM” fantasy

Many MBA grads or consulting-company alums see the Product Manager job as “strategy”.

This is related to a romantic conception of PM as the “CEO of the Product”. And CEOs delegate low-level work to underlings, right? This assumptions leads to the idea of a “strategy-only PM”.

PMs should be responsible for defining product strategy: what to build, for whom, when, and why. But in almost all companies, product strategy can’t be a full-time job because while building a good strategy takes a lot of skill and experience, it doesn’t take a lot of time. If you know your customers and market well, it simply doesn’t take that long to build a solid product strategy and roadmap.

In great companies with great engineers, it might take 10x more calendar time to execute a product strategy than to define it. That’s the best case. For most companies, it’s more like 100x. But it’s always vastly harder to deliver than to dream.

So for strategy-only PMs, what will they do with the rest of their time? There are many possibilities. All of them bad!

They could continue writing and presenting ever-more-detailed strategy docs. But fine-grained long-term planning in a tech business has diminishing returns. Plans usually don’t play out as you’d expect, due to changes in the market, learnings from shipping the first release, or any number of other reasons. Reality forces you to adjust.

Another way strategy-only PMs can keep busy while waiting for teams to execute is to become the Strategy Police, micro-managing the team’s output without actually doing the execution work required to speed up the team’s delivery. This sometimes can help, but mostly it just makes the rest of the team resentful.

Another thing strategy-only PMs may do is to start intruding into the strategy of other teams, like Marketing or Sales, in an attempt to carve out a wider role for themselves driving cross-team strategy. This also annoys colleagues and often pushes PMs out of their comfort zone of product and business strategy into areas where their experience and instincts add even less value.

I could keep going with more examples, but you get the idea: PMs need to spend their non-strategy time helping the team to deliver on the strategy, not finding some other make-work in the meantime.

And if a PM says that they need 40+ hours per week simply to define the strategy, it’s a sign that they don’t know their customer or market well enough, or a sign that they can’t build a strategy. Or both!

Don’t PMs in Big Companies have Strategy-Only Jobs?

BigCo PMs sometimes brag that they exclusively focus on strategy.

I have good friends who are PMs at Meta. Ben is correct that Meta’s engineering teams tend to handle much of their own project management. So what do PMs at Meta spend most of their time on? From what I hear from my Meta friends, it’s *not* defining the strategy and roadmap, which (like in startups) doesn’t take that long.

The rest of their workdays are filled with BigCo-specific coordination tasks:

• Hours every week in cross-team meetings simply to keep work on track. Meta even has a special acronym for this work—“XFN” meaning “cross-functional”—and PMs’ annual performance reviews rate them on these skills!

• Hours preparing slides and documents for executive reviews, and following up with executives afterwards to make sure their feedback is incorporated in the plan.

• Socializing plans with different teams and executives so that the high-pressure meetings above actually go well.

• Learning about what other teams are doing, and adjusting strategies so that they align (or at least don’t conflict) with their own team’s strategy.

• Responding to changes in direction or re-organizations that are internally driven, rather than responding to customer feedback. If you have a new manager or a new team every 6-12 months due to org churn, it takes a lot of time to adjust!

• Lobbying senior management for budget and approval to actually execute the strategy that they’ve defined, and defending their budgets and approvals against other teams’ priorities.

This is not unique to Meta. I was a BigCo PM for many years before switching to startups, and the list above was a big part of my job there too. Personally I prefer startup-style execution, which is mostly working directly with engineers, designers, and customers.

PM roles without strategy are also bad!

Many PMs get pigeonholed into non-strategic roles where their entire job is focused on executing decisions made by someone else. For good PMs, this creates a backlash which can look like this:

If you’re a PM in a job where you don’t define the strategy that you execute, then you should have a frank discussion with your manager about why.

It could be that they don’t trust your instincts or knowledge about the market. And don’t assume that your manager is off-base about this! Business strategy can take a long time to learn how to do well. Don’t expect to drive everything overnight.

It could be that your manager is inexperienced or uncomfortable with delegation. It could be that they’re trying to shield you from something they don’t think you want. There are lots of other possibilities. You’ll never know until you ask!

It’s a great opportunity for you to ask for help in how your job can be more strategic. Not strategic-only, but strategic *and* implementing that strategy.

SaaS Product Managers hear contradictory advice when it comes to competitors:

• Don’t worry about the competition; instead focus on making customers happy!

• Be obsessed with beating your competition!

The answer, of course, is “both”. You need to build great products, and you need to ensure that your customers choose your great products instead of someone else’s.

I’ve spent many years in highly-competitive B2B markets at Microsoft, then at Splunk, and most recently as Head of Product at Cantaloupe which is the largest SaaS provider in the global vending industry. At each of these companies, I had a lot of fun taking market share from entrenched competitors while fending off upstarts. Of course I made some painful mistakes too.

Below I’ll share some ideas and techniques that I’ve found useful in competitive environments. This post will be most familiar to PMs working in SaaS startups targeting midsize-to-enterprise customers, although many lessons may be more universal.

To beat competitors, first you need great products and customer love

Competitive strategy only matters if your customers like using your products and working with your company! A PM’s top-priority responsibility is understanding what customers need most and improving the product to meet those needs.

Competitive strategy is about *how* to improve your products in ways that will make it easier for customers to pick your product when it’s being compared head-to-head with others.

My favorite competitive strategy is trivially simple: build stuff that customers need that your competitors can’t easily build.

Compete where you have an unfair advantage

The worst thing you can do is to go up against a competitor where they’re strong. Don’t start a price war with a competitor backed by Softbank or Tiger. Don’t try to compete with Apple on hardware design. Don’t compete with Oracle on the sleaziness of your Sales team. They will always win.

Instead, I use a two-question framework to find opportunities to beat competition:

• What is my company *much* better at than my competitors?

• Where are my competitors unable to compete?

Your job as a PM is to find the intersection of those two sets, and lean into it!

It’s important to honestly appraise long-term differences between your company and the competition. Ignore transient wins that are easy to copy, like a great feature or high market share. What matters are “moats”: strengths of yours and corresponding weaknesses of your competitors that will stick around for years. Maybe forever.

Lately my favorite example of this strategy is Convex, a startup that’s competing with AWS and other cloud providers by making it easier for JavaScript developers to store data and run code in the cloud. AWS’s strengths are low cost, high scale, and wide range of services. AWS’s weakness stems from its fundamental philosophy that favors high scale, low price, and multi-service architecture. The result is a poor fit for developers who just want an easy, scalable way to store cloud data and run cloud code without complex configurations or integrations. Fundamental technical philosophy is *very* hard to change, which makes it a good target to compete against!

Another example is Apple’s M1 processors in 2020-and-later Macs that “essentially process twice as many instructions as AMD and Intel CPUs at the same clock frequency” while delivering up to 2x the battery life of high-end Windows laptops. In an industry where competitors are usually within a few percent of each other, this is an astounding leap.

Apple made this leap—conveniently for the purpose of this post!—by focusing their improvements in areas where their competitors can’t easily match:

• Apple achieved performance, power, and probably cost gains using a SoC (“System-on-a-Chip”) architecture. This SoC approach works vastly better—both technically and as a business model—if the CPU, computer hardware, and OS are all designed by the same company. That “same company” doesn’t exist in the PC world.

• The M1 processor’s lowest-level language (“ARM instruction set”) is particularly well-suited for huge performance gains that Intel and AMD cannot match because their x86 instruction set is required to stay backwards-compatible with older processors.

This was smart competitive strategy. Apple could have put R&D into other areas that would also improve speed or battery life, but instead they chose to focus innovation where their competitors were fundamentally constrained by business model, technical architecture, and/or backwards compatibility. This means that to catch up to Apple, competitors can’t just clone what Apple did—they need to find brand-new innovation, which is much harder and riskier.

Competitive case study: turning “feature-rich” into a liability

This section is a case study from my own experience at putting this “invest where you’re strong and they’re weak” competitive strategy into practice.

At Cantaloupe, our largest competitor was a conglomerate that sold vending machines (we didn’t sell those) but who’d many years before acquired a vending-focused software product that *did* compete with us. The competitor’s software was the unquestioned industry leader: it was reliable, widely used, and very feature-rich. It had been the best software in our industry for almost 10 years. Also, because our competitor’s primary business was selling hardware, they invested minimally in software R&D and were happy to sell their fully-depreciated software at a very low price (or even give it away for free!) to customers who bought hardware too.

Therefore, competing with them on feature parity or price would have been a long, expensive mistake because we’d be playing where they had a home-court advantage. Instead, we targeted their weaknesses.

Their biggest weakness was, as is typical of successful incumbents, that their tech was old. Their main product was built on “client-server” architecture, requiring Windows desktop apps and an on-premises SQL Server database. Ours was a cloud-based system. So we focused our sales and marketing strategy around around the advantages of the cloud: easy to work from home or on the road, can use any computer or even iPads, no need to pay for buying and maintaining an on-premises server, etc. Ironically, the same thing that made their product successful—hundreds of features—made it impossible for them to respond quickly because moving to the cloud would mean rewriting all of them.

We used the same strategy against their high-quality, feature-rich mobile app for drivers who filled vending machines. Like all mobile apps in the vending industry in the early 2010s (including ours!) our competitor’s app ran on ancient Windows Mobile ruggedized handheld devices that cost more than $1000 and broke down frequently. We knew that the competitor’s mobile app—like their desktop app described above—had a long feature list. Porting it to another platform would take years. So we stopped all non-critical investment in our own Windows Mobile app and tasked our team to build an iOS native app that could run on sub-$200 iPod Touch devices, iPads, or users’ own iPhones. Even though the V1.0 mobile app we shipped had only a fraction of features, because it ran on a cheaper, more reliable, and more usable platform we could already use it as a competitive wedge to win customers.

A side effect of going after competitors where they’re weak is that your “offense” often forces them to play defense if they start losing business to you. In the case described above, our competitor did eventually release a native iOS mobile app and moved at least part of their software to the cloud. But this was a massively expensive project for them. This work kept much of their team busy for several years! By investing in areas where our competitor would struggle, it distracted them and prevented them from threatening us where they were strong but we were weak.

Of course, while you’re trying to force your competitor to compete where you’re strong, smart competitors will be trying to do the same thing to you. Don’t take the bait! Don’t assume you need to respond to everything a competitor does. Be willing to lose deals in areas where your competitor is too strong, so that you can stay focused on areas where you’re stronger. It’s a game of chicken; the longer you can stay focused on your own strengths, the better your chance of winning the game.

Feature parity 101: when and how to compete where they’re strong

So far in this post, I’ve tried to convince you not to fight the competition on their home turf, and not to get sucked into a feature-by-feature slog with an entrenched competitor. But this advice isn’t universal. As you move upmarket, you’ll likely bump into the bane of every SaaS company’s existence: “feature parity”, where large customers insist you fill feature gaps relative to competitors.

In the early days of most SaaS companies, competitive feature parity is not important…because it’s not possible! You can’t build in 6-12 months what the competition has built over 6-12 years. Instead, you should carve out a niche where your features are 10x better than anyone else, and you need to sell those features to early adopters who tolerate your gaps in return for a best-of-breed solution in a narrow area.

But as your product matures, you’ll run out of early adopters! Also, you’ll start landing larger and more complex deals. You might even start taking business away from once-untouchable competitors. But what you’ll find with these larger deals is that feature gaps can be deal breakers. This is especially true when you’re trying to eject a competitor from an account, because you’re not only competing with a competitor’s salesperson. You’re also convincing an entire company, often hundreds of people, to change how they work by adopting your theoretically-better product over the competitor’s unloved-but-familiar product.

In those cases, your customer will typically present you with a list of feature gaps. It usually sounds like this: “We love your product and we want to throw out [competitor’s product “X”]. But X does a really great job at A and B. If you build those things, we’ve got a deal.” If this is the only customer who’s ever asked for A and B, read my post How to Avoid Building Custom Features for One SaaS Customer! And if the customer asks you to fill 20 different gaps or gaps you can’t realistically fill, then you’ll have to say no.

But if you’re hearing the same few feature gaps in many high-value deals, you might decide that it’s time to stop losing those deals. It’s time for feature parity…at least in those features. Here’s how I approach it.

First, the default answer should always be “no”. Customers and salespeople love to blame feature gaps for not closing deals. Often the deal can be done anyways, given the right incentives. If I’m not 90%+ confident that a feature is really needed to close a lot of business or prevent a lot of churn, then I’ll partner with Sales to see if we can solve the gap with money instead of engineering, or otherwise stall to see if the deal gets done anyways.

But in cases where stalling is not possible, what next? I’ve learned from painful experience what *not* to do: don’t spend a lot of effort building a feature that’s roughly the same as the competitor’s. This may solve your immediate sales pain, but it’s easy to fill up your roadmap with parity work and still not catch up to an entrenched competitor for many years. Chasing parity can slowly bleed your company to death.

Instead, I generally bifurcate all feature parity decisions into two strategies: “least effort” for most features and “leapfrog” for a few rare cases. In other words, either get to “good enough” with a bare minimum investment, or deliver something that’s so much better than the competitor that what was previously your weakness is now your strength. I avoid the middle path that fills up the roadmap but doesn’t generate sales or marketing wins.

Feature parity example: “least effort”

A good example of “least effort” came when my Head of Sales called me late one evening. Our largest customer—who’d recently turned off our competitor’s software and was now using ours instead—was very unhappy and threatening to go back to the competitor.

The problem: many tasks were taking their team 5x+ longer than when using the competitor because our app was slow to display very large datasets on some pages. This customer’s staff were waiting 3 minutes for some pages to load! This was a known problem on a few pages of our JavaScript-heavy web app. This didn’t affect our competitors’ native Windows client apps, but our previous customers using these features were smaller so our pokiness had never been a big problem. But the customer’s team was used to our competitor’s product that loaded equivalent data in under one second. I didn’t blame them for being upset!

We had two options: delay our roadmap by a month to re-tool how our app displayed large tables of data and match our competitors’ sub-second load time, or figure out a cheap way to make this customer’s pain less bad. We chose the latter. After a day or two of tactical fixes, we reduced three-minute load times to 45 seconds. Still awful, but better. Later, we deployed another fix that brought it down to 15 seconds. Still annoyingly slow, but that was fast enough that the customer stopped threatening to churn.

This episode was classic least effort: we didn’t try to beat the competition; we just tried to make our gaps “less bad enough” to avoid losing business.

Feature parity example: “leapfrog”

My favorite win against this same competitor—and an example of “leapfrog” feature parity—was in reporting features. Our competitor’s product had hundreds of high-quality canned reports, and used a solid Crystal Reports-based reporting UX that allowed advanced customers to hire database developers to build custom reports directly against the local SQL database. Our product, on the other hand, had limited reporting features, few canned reports, and no self-service custom reports. If a prospect’s top priority was reporting, we’d lose the deal.

We’d had a big reporting overhaul on the backlog for a while, and in the meantime we were improving reports in a “least effort” fashion while we worked on higher-priority stuff. Then we got big news: our top competitor had just acquired its largest competitor. The acquired product was even more ancient—many of its customers still ran a DOS version! But the acquired product had one huge advantage: a much-loved reporting feature that let non-technical users build custom reports without hiring a database developer.

Like most B2B acquisitions, we assumed that within the next two years the acquirer would try to force acquired customers to migrate to the acquirer’s software. This was an opportunity to win those customers. If they must switch, why not switch to us?

One problem: our reporting sucked. We had neither easy custom reports like the acquired competitor, nor the massive library of custom reports and SQL-level extensibility like the acquiring competitor.

After learning the acquisition news, we decided to leapfrog the competition. It was a massive effort: a big chunk of engineering time for more than a year. But in the end, this big bet paid off. We went from worst-in-the-industry reporting features to best-in-the-industry. This unblocked many sales deals and further frustrated our top competitor by converting many of their acquired-company’s customers!

Note that we didn’t try to get reporting feature parity everywhere. We still didn’t have a way to do SQL-level custom reporting like our top competitor offered. Instead, we focused leapfrogging investment where it mattered most: on acquired-company customers who really liked what their old product gave them: the ability for non-technical users to make custom reports. This was an important lesson: even when leapfrogging, you still need to be very selective about *where* and *why* to invest.

Different competitive strategies for different competitors

To understand a competitor, I’ve found it helpful to understand what *kind* of competitor it is. I divide them into five types:

• Legacy Competitors: established players in your industry with mature products. These competitors tend to be larger, slower-moving, better capitalized, more feature-rich, more sales-and-marketing-focused with weaker engineering, and better known than your company and its products.

• Emerging Competitors: smaller startups going after you and the legacy competition… just like your company did when it was a brand-new startup!

• Unexpected Competitors: companies from an unrelated industry who are taking business from you and your competition. For example, at Cantaloupe our customers (vending operators) often had a line of business called “Office Coffee Service” that delivered coffee, snacks, and supplies to corporate break rooms. Costco and Amazon have started to play for that business by delivering similar products at lower prices. For our customers who were used to peer competitors only, this was a shock.

• Bad Competitors: companies who aren’t executing effectively. They might have always been bad, or they might be legacy or peer competitors who have lost their way.

• Peer Competitors: companies like yours, Hertz and Budget if you’re Avis. Or United vs. Delta. Similar size, similar customers, similar market.

For each kind of competitor, you’ll need a different competitive strategy:

• Legacy Competitors are the best competitors for startups! They’re slow, they make lots of $$$, and customers often hate them. Taking business away from legacy competitors is also where most of a startup’s revenue comes from after early adopters are exhausted. For these reasons, I generally try to steer towards legacy competitors because they’re relatively easy to beat, and because their customers are usually so grateful that they’ll reward you with praise and money when you give them something better.

• To Emerging Competitors, *you’re* the legacy! The playbook here is usually straightforward: most smaller-than-you startups have a thin product, few reference customers, sloppy engineering, bad reliability, and will probably go out of business in a few years. The goal: prevent these competitors from getting a toehold in customer segments you care about most. It’s mostly up to the Sales team to accomplish this, so I think PMs should worry less about these startups as competitors and more as opportunities: for learning other ways of solving the same problems, as potential partners, as potential acquisition targets, etc.

• To compete with Unexpected Competitors, the trick is usually to leverage your better knowledge about the customer and the industry. When a big company from another industry tries to muscle in, they often have advantages, e.g. better pricing, more scale, etc. This may mean conceding “commodity” lines of business to them. But they have a weak spot: they haven’t spent years specializing their product and company around your industry like you have. Exploit that unfamiliarity! For example, imagine I run a same-day delivery business and DoorDash or Amazon or Uber enters my market. I might choose to give up the generic “deliver anything” market where they will have the advantage in scale and/or price. But I might specialize (and win!) in more complex deliveries with unusual logistical, legal, or other requirements: medications (need temperature control and/or special legal controls), flowers (need to be kept fresh), frozen foods (need a freezer), construction materials (need a flatbed truck), and so on.

• Bad Competitors are an interesting case. First, you need to be sure they really are bad. Talk with their customers to confirm. Second, beware of legal or interpersonal issues; when companies are on their way down, they often try to take others with them. Third, these are often prime acquisition targets, because they often have a long list of dissatisfied current customers that you can mine for leads. Just be aware that customers who have stuck with a Bad Competitor for this long may be so change-averse that they may not be easy to close nor a good customer afterwards, so the value of that customer list should be discounted. Otherwise, they are good targets for your Sales team but from the Product side I usually don’t worry much about them.

• Peer Competitors are my least favorite. If a competitor is a similar size and maturity as your company, then it’s harder to find areas where they’re weak and you’re strong, and easier for them to do the same to you. Unlike the others above, there’s no simple strategy that works for peer competitors. You’ll have to figure it out on a case-by-case basis. My only advice is to try to avoid head-to-head matchups with peers. Often you both lose. It’s usually better to find parts of the market where peers aren’t playing, and claim those niches before your peer competitors can respond. Once you’re entrenched, it will be harder to boot you out.

As an established startup, you’ll likely have all 5 kinds of competitors. But there’s only have one roadmap! For this reason, I’m always on the lookout for product investments that address multiple kinds of competitors at once, often for different reasons.

For example, Cantaloupe’s revamped reporting features (see “leapfrog” above) addressed all five competitor types. Our new technically-challenging reporting back-end put parity out of reach of all competitors except the Unexpected category. And the vending-industry-specific data that we were reporting ensured that an Unexpected Competitor would be unlikely to get the results right, even with great data-science tech.

“Defend against everyone” features like our reporting work also tend to be the most valuable from customers’ POV too, so they usually rise to the top of every roadmap.

Competitors help you learn quicker

A nice thing about competition is that it helps you understand your own market better. You learn which business strategies and features resonate with customers and which don’t. Competition helps an entire industry get better faster and deliver better products to customers and users. I think this is the gist of Brett’s advice below.

Here’s a few quick tips for using competition to learn about your customers and your industry:

• Whenever I chat with a customer, I politely ask what they think about the competition. I ask what they like, what they don’t, and anything particularly cool or awful that they’ve seen. As long as you keep the focus on what the customer thinks (“What do you like about product X? Do you think that they do a better job at feature A than we do?”) then most customers are happy to share. Occasionally customers are shy about some things (e.g. pricing is often a sensitive topic) so don’t push it.

• When visiting a customer who uses a competitor’s product, I often try to get a demo where they show me what they like and don’t like about the product. Just be careful not to seem like you’re using the customer to sneakily gather private info about the competitor. Don’t push it. As noted above, the best way for this not to feel awkward is to ask the customer about their opinions and let them lead you to the right info. For example, instead of “Could you show me the New Report feature of this product?” try this instead: “I noticed that there’s a “New Report” button on your screen. Do you use that feature?” Then pause and wait. 9 times out of 10, they’ll click the button and give you a demo, while giving you a detailed review of what they like and don’t like!

• It’s helpful to join competitors’ webinars, drop by their booth at conferences, and otherwise get a holistic view of how they’re talking to their customers. By watching how customers respond to someone else’s sales and marketing pitch, it’s a good way to judge whether your own company’s messaging is on-target or not.

• When our company would lose a deal, we’d always do a “lost deal analysis” where the salesperson (or sometimes the Head of Sales, or occasionally even the CEO) would check in with the customer to understand more about why we lost the deal. This info is invaluable, but needs to be extracted humbly and politely. We’d often check back in with a lost deal 6-12 months down the line, where info is often more unfiltered and useful than the immediate aftermath of a lost deal, because the honeymoon period is over and the customer wants to gripe. BTW, this is a great time for Sales to try to try to win the customer back.

Other Tips & Tricks for SaaS Competition

This section is a few observations that may help when thinking about competition, and also some competitive practices or techniques that I’ve found useful.

Don’t badmouth your competitors

My one iron rule for competition: I never talk trash about competitors in public, in the press, or (especially) in front of customers. Customers *hate* it when vendors badmouth each other because it puts the customer in an awkward position, especially if they have to work with both companies. Don’t do this!

Also, it’s common for employees to switch companies in the same industry. If you’re known as a company that’s disrespectful towards competitors, it gets harder to attract good talent from competitors who may not want to join that culture. Also, you’ll attract jerks who *do* like that culture.

Competitors will train customers to pay for software. That’s good!

In SaaS, your biggest “competitor” is often not another product: it’s a free combination of Excel, email, post-it notes, and other ad-hoc solutions that your customers have been using to solve a problem that you want to solve with your software.

This often means that new products who lack competition from other software vendors still must compete with the status quo. They need to convince customers that the in-house duct-tape solution should be thrown away in favor of your (probably expensive) product. This can be hard, especially when there’s an internal constituency for the duct tape solution.

So often it can be helpful to have competing products in a market, because they have already trained customers to pay for software to solve a problem. In my experience, it’s often easier to dislodge a competitor than to kick out a bad internally-developed solution.

Your competitors are better and more numerous than you probably think

Most people in most companies are overly confident about their competitive position. They start to believe the marketing spin exemplified in “feature checklists” like the one below, where your company is all green while the competition has lots of missing parts.

It’s normal for the marketing team to think that way, but as PMs we need to be more objective and clear-eyed about our competitors. A good way to be reminded of this is to visit or meet with our competitors’ reference customers (often I’d tag along with salespeople for this) to see the best examples of our competitors’ products in action, and to hear what their biggest champions say about them. It’s humbling, but it’s also a useful anchor to reality.

Also, never say “we have no competition”. By claiming you don’t, it makes you sound like you haven’t done your homework or are arrogant. Probably both.

Competition isn’t only about features

From a SaaS customer’s POV, the “product” they’re buying is actually the *company*, not the software. I first learned this at Splunk; the product got much better over time, but when I first joined it was hard to set up, hard to use, and hard to extend. But our Support team was great, so if a user had a problem they called or emailed Support and quickly got back on track.

I saw the same at Cantaloupe, where customers were willing to pay a higher price because working with our company was easier than the competitors: we had good support, our salespeople were more ethical, and our people were more focused on solving customer problems.

The takeaway is to compete at end-to-end customer experience: not just product features but also documentation, support, billing, salespeople, and more. I’ve repeatedly seen that over-investing in customer relationships makes it easier to sell high-margin products and to beat low-price/bad-service competition.

For more about widening your too-product-centric worldview, check out Product is a Feature (of the Service).

When Should You Worry About a Competitor?

Most industries are crowded. You probably have 20+ competitors: usually a few large players and many smaller startups trying to claw their way to the top. But it’s not a good use of scarce time to become an expert in all of those small startups. Most will fail and time you spend on them will be wasted.

Instead, I typically use a simple heuristic for where to focus my competitive attention:

• Competitors who are strongest among “stretch” customers. The typical path in SaaS is to start with smaller customers and gradually move upmarket. This means that the most challenging deals to win are on the “leading edge” of your customer base: customers as large or slightly larger than your current largest customers. In order to win more of those leading-edge customers, you need to beat competitors who play there. Keep in mind that winning the first stretch customer will likely be *very* expensive in every dimension: engineering work, sales discounts/rebates, customer service, etc. The second, third, etc. should get cheaper (aka more profitable) as your company gets used to handling customers of that scale.

• Competitors I hear a lot about from Sales. Good salespeople often (although not always!) have a sixth sense of whether a competitor is a threat or not, because they spend every day talking with customers and therefore hear which companies are really a competitive threat vs. a vapor threat. Customers will sometimes exaggerate the chance of a competitor winning a deal in order to extract concessions, and some salespeople won’t see through this strategy. So don’t over-react. But if I hear about the same company showing up in competitive deals across multiple salespeople, then it’s probably worth learning more about that competitor.

• Competitors I want to learn more about. These can be potential acquisition targets, potential partners, companies with interesting technology or business plans, or other factors that make the competitor more than just “a company I want to take business from”.

A simpler approach is to only pay attention to a competitor until you start losing deals to them, which ensures that you don’t waste time on vapor competition. But I think this is too risky, because losing deals is a lagging indicator. By the time a competitor beats you in an important deal, they may have enough inertia that they’ll be able to beat you in other deals too, and it may be too late to catch them easily. It’s easier and cheaper to head them off when they haven’t matured enough to actually beat you in deals.

One thing I don’t focus on is competitors who are getting a lot of buzz in the press, but who aren’t actually showing up in competitive sales situations and who don’t seem to fall into the “want to learn more about” bucket above. Some companies are better at getting attention than others. Don’t get distracted. The only attention that really matters is the attention that comes out of customers’ wallets. 😊

Happy competing!

Around year 4-5 of most startups, a funny thing usually starts happening: the engineering team can’t ship new features as fast as it used to.

At first, the problems feel like isolated issues: a release might get delayed a week; a feature might take 2x as long as the estimate; a buggy release might have to be rolled back; or the team might get pulled off feature work to handle a critical performance bottleneck. But the underlying pattern is unmistakable: after years of shipping features at a fast pace, the company has built up so much technical debt that new feature development slows to a crawl while reliability, performance, and security problems proliferate.

Companies generally take one of three approaches to tech debt:

• Ignore it until it’s critical, then stop everything for weeks or months to fix it. For example, at Microsoft during the early 2000s security problems forced the entire Windows team to pause feature development for about a year to ship a bugs-and-security-focused update: Windows XP Service Pack 2. This free update cost the company billions of dollars in upgrade revenue.

• Proactively schedule “tech sprints” where engineers do refactoring, bug fixing, and tool upgrades in big few-week bursts each year, and then go back to feature development and debt accumulation for a few months.

• Consistently budget for tech debt in every sprint or iteration. Instead of big-bang tech sprints, this approach pays down debt in small chunks over time.

Most startups start with “ignore-until-critical.” This is usually the right business decision for early-stage startups. Why polish your underlying tech if you don’t even know if the market will buy your product, or if you’re planning to rewrite your code when you can afford to hire experienced engineers? Shipping as quickly as possible usually trumps all other concerns.

But as a startup matures, good companies recognize the risk of ignore-until-critical, if not proactively then often after the Nth major outage or performance issue.

My last startup Cantaloupe, the largest SaaS provider in the global vending industry, was no exception. One of the first meetings I attended as VP Product was an all-day “war-room” meeting to deal with a major outage. It was a symptom of a mountain of technical debt.

I joined the company soon after our CTO and Engineering Manager did, and together we agreed that tech debt was a problem and retiring it should be a priority.

We started with the Tech Sprint model, scheduling 3-4 per year. These helped us avoid more major outages, but it was clear after a while that this model wasn’t perfect:

• Engineers were mostly paying down recently-acquired debt while not addressing larger, longer-term challenges.

• Upcoming tech sprints were used to justify delaying test automation, performance work, and other critical parts of new features.

• It was always tempting for business concerns to delay a tech sprint, so “3-4 tech sprints per year” inevitably meant 2.5-3.

A few years later, a new Engineering Manager was hired and he convinced us that the “Tech Budget” model would be better. Spoiler: he was right! But what’s interesting to me (and maybe to you too!) was *why* it was so successful, and what we learned about how to make it work even better. That’s what the rest of this post is about.

Tech Budget: How it Works

After a few years of experimentation and refinement, we learned that there were three core ingredients to a successful tech budget:

1. Allocate a fixed % of engineering capacity in every sprint to technical tasks.

2. Use the same process and prioritization that’s applied to feature work.

3. Engineers, not PMs, should manage and prioritize the tech backlog.

I’ll discuss each of these in turn, explaining how they work as well as tips for making them work well and pitfalls to avoid.

Allocate a fixed % of engineering capacity to technical tasks

The key to a successful tech budget was that it never varied. Making it always the same yielded many benefits:

• Forecasting was easier because capacity (for both feature work and tech work) was predictable over time.

• The inertia of a number that never changed helped to discourage PMs and executives from “borrowing” tech time. A fixed number made it easier for everyone to think of changes as rare exceptions rather than a constant negotiation.

• It was simple, so everyone at the company could understand the plan.

• It made it easier for engineers to work on long-running projects that required pauses in the middle, for example adding performance instrumentation in one release and evaluating and acting on the results after a few weeks of data was gathered.

• It let engineers align tech tasks with related feature work. For example, if a new feature required reworking the schema of a database table, the team could also spend a few days to optimizing database indexes and query performance.

• It made it less painful when a tech task didn’t fit into a sprint. In the old Tech Sprint model, engineers were tempted to shove more work into a tech sprint than they could safely finish, because they knew it’d be months before the next tech sprint. Knowing that postponed tech work could be finished in just a few weeks avoided these risks.

• Some engineers really liked doing tech tasks while others preferred to work mostly on features. Some engineers liked to do a little of both. Others only liked doing tech tasks about specific topics; for example we had one engineer who was passionate about improving our UI test automation framework. Mixing tech tasks and feature work in the same sprint allowed engineering managers to tailor tech work assignments to to each team member’s preference. This helped morale and productivity.

The “right” percentage is probably between 15%-30% depending on the company’s needs. We had a mountain of debt and a relatively junior team, so we settled on 30%. But I think we also could have been successful at 25% or even 20%. Honestly, the number mattered less than the habits encouraged by having a number and sticking to it.

Use the same process and prioritization that’s applied to feature work

The second tenet of the Tech Budget is that technical tasks should, wherever possible, follow the same rigorous process that the team used for feature work. This means formal estimation, written specs with enough detail for engineers to estimate the work, putting tech tasks in the issue tracker, scheduling them in a sprint or kanban lane, maintaining and grooming a “tech backlog”, etc.

The benefits of doing this included:

• The team was familiar with the process, so they didn’t need to invent something new and untested.

• The same reports and metrics could be used for both feature work and tech tasks.

• It made company-wide forecasting and metrics (e.g. for auditors) easier because there was only one bucket of things to measure.

• It made it easier to spot disparities, e.g. estimates being more accurate for feature work.

• By creating a Darwinian competition between tasks in every sprint, the quality of tech tasks went up because it's usually easier to find the top handful of tasks for each sprint than to ensure that 30+ tasks in a tech sprint are all “highest priority”.

• It avoided risky megatasks by forcing large changes to be chopped up into manageable, testable, “checkpointable” chunks that could fit into one sprint.

We were already doing all these things for feature work, and doing them for essentially the same reasons. So it was an easy adjustment for the team to do the same thing for tech tasks.

But there was one really, really important process difference…

Engineers, not PMs, should manage and prioritize the tech backlog

We quickly realized that PM involvement was not needed in tech tasks. This saved a lot of Eng and PM time. For example, sprint planning meetings (our largest and therefore most “expensive” meetings) were shorter because they could ignore tech tasks. To prioritize tech tasks for each sprint, engineers met in a smaller group after the sprint planning meeting and decided which tech tasks would make it into the sprint. Because this smaller meeting could be done at a time and place of the engineers’ choosing (e.g. in a different time zone, or with beer!) it made planning more more efficient and more pleasant for them.

Also, PMs didn’t have to learn the technical details behind each tech task, and engineers didn’t have to waste time educating PMs about work that users would never see. This helped keep PMs focused on delivering features to customers instead of having to care about tooling upgrades and code refactoring!

Tech Budget: Tips, Tricks, and Problems

Like every good thing, the Tech Budget has some challenges and gotchas. Here’s a few that we found, along with tips to work around them:

Taxes suck (but insurance is tolerable)

The hardest part about the Tech Budget was paying that big tax on every sprint. But I looked at it like this: the 30% tax was the price we paid to avoid outages and to continue to ship features at a consistent pace. I tried to think of it as “roadmap insurance”: a predictable downside in exchange for preventing long-tail risks that could endanger the company and prevent us from delivering on the product roadmap.

Having roadmap insurance also meant that I could be much more secure in schedules and forecasts, because doing continual tech investment vastly reduced the chance that we’d have to cancel half the roadmap for a year in order to rewrite a lot of rickety old code.

Being more secure in the roadmap had good ripple effects beyond Product. For example, it made it less risky to share our roadmap with trusted customers. This helped salespeople win larger deals. It also built our investors’ confidence that we knew what we were doing, which made the CEOs job a little less hectic.

Did all those benefits mean I was happy paying that big tax every few weeks? No! I never got used to it. But like broccoli and motorcycle helmets and other things that are obviously good for you, I was OK with the tradeoff.

Borrowing from the Tech Budget should be rare and quickly repaid

Especially during crunch times where we really, really wanted to complete an important new feature, it was soooooo tempting to try to steal tech time.

When we occasionally needed extra feature work, we horse-traded with the engineering team for a few points, which we always repaid in the next sprint. Of course, both groups need to trust each other. Borrowing only works if Product actually returns the points!

Similarly, Eng may occasionally need more Tech Budget in a sprint, e.g. to complete a huge refactor. As long as this is rare, PM will win a lot of gratitude if you stay flexible.

But borrowing should be very rare, or you lose many of the predictability benefits of a Tech Budget. If you’re borrowing more than a few times per year, that’s probably too much.

Defining tech tasks vs. feature work can be tricky

Another challenge with the Tech Budget was jockeying that went on between developers and PMs around “borderline” tasks that could be considered feature work and could be a tech task.

Obviously, code refactoring and build-tool upgrades were tech tasks, while new mobile app screens were feature work. But what about addressing customer complaints that pages were slow to load? Is fixing page-load performance a tech task or feature work?

We solved this dilemma by using a simple heuristic:

• Tech tasks were work required to maintain the *current* level of performance, stability, and security despite increased usage and server load. This includes regressions in functionality and performance.

• Feature tasks were about *improving* customer experience beyond its current state, including performance and (especially) anything that made a change to user-facing UI.

Another shortcut was who wanted it. If PMs were asking for it to be in a sprint, it probably wasn’t a tech task. Conversely, if a bug really annoyed an engineer but PMs didn’t think it was important enough to fix, then the engineer could lobby her teammates to fix it a a tech task instead.

One important related point: tech tasks aren’t just about fixing old code. If the engineering team wants to, they’re free to use the Tech Budget to introduce new testing tools, to upgrade frameworks or libraries, to migrate to a new platform, or any other task they think is needed to make their work easier or to improve the infrastructure or code. Or to add Easter eggs! 😄

Test automation for new features is part of feature work, not tech tasks

Following the new vs. existing heuristic described above, tests for new features should be considered part of feature work, not tech tasks. Releasing features without automated tests is a recipe for disaster a few months down the line, because manual testing will slow down each release until it takes weeks to ship every version. Don’t do this!

Adding test automation for existing legacy features, or adding new kinds of tests (e.g. UI automation, load testing, penetration testing) should be part of the Tech Budget.

Don’t start huge tech tasks without letting PM know

Engineers should be free to make day-to-day technical decisions and to manage the Tech Budget without some nosey PM micro-managing and distracting them.

But PMs should definitely be consulted for big architectural decisions, like:

• Should we switch from Oracle to Postgres for all our customer data?

• Should we move from AWS Lambda to Cloudflare workers?

• Should we kick off a year-long test automation push?

• How are we going to scale to 10x current load?

• How should we support our first non-English customers?

• How much effort should we put into improving performance?

Note that “consulted” doesn’t mean that PM should drive or veto these decisions. Engineers are the owners of technical decisions. But PMs should be involved, where I think “involved” should mean at least:

• PM understands the reason for doing the work, and can explain it to others in the company who question why it’s needed.

• PM understands the costs and benefits of the work, and the tradeoffs.

• PM understands the risks and fallback plan in case the work doesn’t go as expected.

• If there are several options being considered, PM should be exposed to those options and should inject a customer/business perspective as options are being weighed against each other.

• Engineers should try to convince PM that the work is justified. If you can’t convince the PM you work with every day, then do you think you’ll convince your CEO or head of Marketing who won’t have the patience or interest to learn the details? Convincing PM is a helpful dry run for other, more-skeptical folks.

• Engineers should be willing to entertain concerns—especially about customer experience or risks to the roadmap—that PMs bring up. Code exists to serve the business, not the other way around. PM input, as long as it’s focused on customer and business outcomes, may help you avoid worst-case scenarios like the company going bankrupt before the big infrastructure project is done!

In practice, PMs serve in an advisory role for these kinds of big architectural decisions. They can be a helpful set of eyes to make sure that a big investment is made with buy-in from the business and awareness of what can go wrong. This will pay off later, especially if the work gets into trouble.

Don’t call them “Eng Tasks” and “PM Tasks”

A small but important learning: it’s easy to think of feature work vs. tech tasks as “stuff PMs want” and “stuff engineers want”. This sets up an us-vs-them vibe that isn’t good for team cohesion.

So I’d strongly suggest you avoid the urge to call them “Eng Tasks” and “PM Tasks”. I like “Tech Tasks” and “Feature Tasks” but any name is OK as long as it’s associated with a concept, not a group of people.

A corollary for PMs: don’t allow yourself to think that feature work is inherently more important than tech tasks. Both are needed for the company to survive for the long term. Don’t be arrogantly PM-centric!

PMs should adapt to engineering process, not vice versa

As a Product person, I intentionally try to be very flexible about engineering process. There are usually 5x-10x more engineers than PMs, so our process should be optimized for making the larger group (engineers!) happy and productive. PMs should defer to engineering leaders on decisions like:

• Whether to use sprints/kanban/etc.

• Whether to organize using a “big pool of people” or “pods”

• Which bug-tracker to use

• What kind of metadata should be in each issue

• How PRDs/specs/user-stories should be formatted and how much detail should be in them

• Which information should be written down vs. fleshed out in meetings

• How many meetings are required for each issue/sprint/etc.

But the Tech Budget is the exceptional engineering-process topic that I *do* have a strong opinion about, because I’ve seen with my own eyes how much of a positive impact it had on our company.

Many thanks to the early readers of this post, and especially to Igor Schtein, who taught me the value of the Tech Budget and who put up with me always trying to steal his team’s points!

Most modern SaaS companies operate in an Agile or continuous-integration process where they ship new features and fixes at least once per month. There’s a lot written online about how to communicate product changes externally. But one thing I haven’t seen much written about is how to help folks inside your company. That’s what this post is about.

Release Emails 101

When I was Head of Product at Cantaloupe, I or someone on my team would typically send a company-wide email a week or so before every release. Here’s the structure we honed via years of experimentation and feedback:

• First, a one-sentence TL;DR summary for the large percentage of the company who like to stay informed but who may not have the time or interest to dig into the details. For example: “This release addresses customer requests for improved custom reporting by speeding up custom reports by 30%-50%, by adding a custom filtering option, and by adding 45 new reports to our report catalog.”

• Next, a high-level list of features and major bug fixes in the release. Ideally, the features are described in non-technical terms from the customer’s point of view, which enables non-technical employees (which are most employees!) to understand what the features are and why they matter. For example: “Custom Report Filtering - reports can now be filtered by any field in the report, using the same easy-to-use column search interface we use to add columns to a report. This was requested by Acme Inc, Consolidated Corp., and many other customers and will reduce the custom reporting work that our sales engineering team has previously had to do.”

• Next, a link to release notes, documentation, training videos, and/or other detailed info about each feature, so that folks who want or need more detail than your short bullet points. You are writing user-friendly release notes and documentation, right? If not, start! I’ve found that having PMs write the first draft of technical documentation can save a *lot* of time—from PMs as well as others like Support or Sales—by answering questions without having to respond to each question individually.

• Next, a heads-up about what’s coming *after* this release, again keeping things high-level. For example: “The next release will include the first beta release of our new mobile app that you’ve probably seen a demo of in the last all-hands meeting. If you have customers in mind who you think would be good candidates to try the new beta, please let Joe know.” One reason we did this was to address feedback from colleagues who complained that hearing about new stuff a week ahead of time wasn’t enough advance notice. I was skeptical that people would really use the extra time to educate users; I thought it was just an excuse to complain. But after we started previewing future releases the complaints stopped so from my perspective it was Mission Accomplished! 😃

• Finally, and this is really important: thank people! Public recognition for good work is incredibly meaningful, especially to junior engineers and other employees who may not interact with customers directly. It’s your job to show them how valuable their work is to your company’s customers and to the rest of the company. For example: “This release was a cross-company effort, but I especially want to thank Elliott and Jennie on the engineering side and Chuck on the Sales side partnering together to figure out which reports should get built, and Billy from Sales Engineering chipping in to build 37 reports in 4 loooooooong days. Way to go, team!” I’ve heard concerns that public thanking of individuals is risky because you inevitably forget someone. YMMV, but this didn’t turn out to be a problem for us, perhaps because we thanked people so often. Even if we missed someone once, they knew that their next chance in the limelight wasn’t too far away.

The common thread across all the bullet points above is to minimize the level of detail so skimmers can get the gist without putting in a lot of effort, while allowing curious or conscientious colleagues to dig in and learn more.

I found it useful to think of my colleagues like I think of my product’s users: as well-meaning, busy people who have a lot on their plate and who are depending on PM to respect their scarce time by pre-chewing information so it can be digested easily.

Emails Are Not Enough To Train The Company

You’ll probably find out sending out emails for every release is necessary but not sufficient to inform your colleagues. People are busy, and many of them simply won’t read your release emails. Also, some people—I see this a lot from non-technical folks like salespeople—may have a different learning style that works better by learning with meetings or videos versus reading emails. We found that we needed to supplant regular release emails with a more multi-media approach. Over the years we tried many different non-email solutions. Some worked better than others. Here’s what we learned:

• Live “Training sessions” worked very well and were well-attended. For every major release (every 2-3 months, usually) we’d do a combined training session for Sales, Customer Success, Support, and anyone else who was interested.  There was usually a mix of in-person and remote attendees. While folks were in the room, they would often ask questions unrelated to what’s new in that release, which was helpful to backfill knowledge missed previously.

• We’d record the training sessions and folks could watch them offline. Remote salespeople in particular appreciated this because they were often traveling during our live sessions.

• For big milestones or events (e.g. annual industry conference) we’d host training meetings (ostensibly for booth workers) that we also recorded. These recordings served as demo training for salespeople throughout the year, and because we had annual industry conferences it ensured that our demo trainings didn’t get too stale. There was also Q&A during these sessions too which helped with backfilling knowledge as noted above.

• We’d attend Sales meetings at least quarterly so we could exchange knowledge with the Sales team and go over what’s coming soon in the roadmap. This was also a good venue for wide-ranging Q&A and “spot training” on features that the room was interested in.

• Office hours / fireside chats didn’t work well because they require attendees to be proactive to attend.  There wasn’t enough uptake to be worthwhile in our small company.

The overall lesson here is that repetition—especially across time and across different media—can be really helpful to facilitate learning at scale across your company. And providing opportunities to engage in real time—which can be recorded and re-used later—was a cheat code to cheaply educate our team in the future.

Focus on information, not PM self-congratulation

A caveat: the focus of communications to the company should not be “about what the product team is up to/has accomplished”. That’s self-promotion, which won’t help the company. Instead, you should think of release and roadmap communication as a way to help *other* parts of the company to be successful by giving them the information they need to do their jobs better. For example:

• If the Support team knows about how a new feature is supposed to work— and why it was designed the way it was—then they’ll be better prepared when customers contact them for assistance.

• If the Sales team knows what features are being launched, why these features will benefit customers, and which customers are likely to care most about the improvements, then they’ll have useful talking points to reach out to hot prospects.

• If the Engineering team sees that their work is being publicly lauded inside the company, they may be more likely to forgive you for pushing so hard before a big release! Also, more seriously, a problem I sometimes hear from engineers is that they’re not sure anyone cares about the work that they’re doing. I find that these communications—and congratulatory reply-alls from exuberant salespeople, marketers, and executives—are helpful to remind engineers how much their work is valued by the rest of the company.

• If the marketing team has good release notes and a clear roadmap, it will be much easier for them to craft press releases, blog posts, sales training materials, and other communications they need to get leads and to support the Sales team.

And so on. As PMs its our job to ensure that products are successful, and products can’t succeed if the rest of the company doesn’t know about them. So focus on that. Don’t worry about the rest of the company appreciating your work, because if the products are good and customers like them and the company is well-prepared (by you!), then you’ll get lots of appreciation!

One of my favorite interview questions to ask PM candidates is “What’s the biggest mistake you’ve made at work?” In this post I’ll share my own biggest mistake: the time early in my career where I built and executed a product plan that assumed our market would stay the way it was. I failed to anticipate likely changes in the marketplace and likely reactions from our competitors. The only constant in life is constant change, and by forgetting that I doomed our product.

Here’s the story: in my first PM job (at a large tech company) I led PM for a team that designed and built a V1.0 software product that was designed to replace networking hardware that our competitors sold for $5,000 per connected server.

Our business plan was simple: offer comparable but easier-to-use functionality in software, simplify the IT environment (one less piece of hardware to manage!), and sell it for $500 per server. Easier, cheaper: what could go wrong?

It was a good business plan… if we’d launched in a week. But, like most hard things, the product took a while: about 2 years from elevator pitch to initial design to MVP to betas to production release.

In the meantime, the market had changed. Thanks to Moore’s Law and competition, what used to cost $5,000 per connected server now cost 10x less—exactly the price point we wanted to hit! And competitors’ products now had more features and were significantly easier to use.

Our price advantage had evaporated. Our ease-of-use advantage was reduced. And now we were battling entrenched competitors in a more mature space. Predictably, our product failed to gain much market share beyond our enthusiastic early adopters.

What I learned: When building a new business, don’t build the product that the market needs now. Instead, build the product that the market is likely to need several years in the future. Don’t assume that the market and your competitors will stand still waiting for you!

In a standalone, well-funded company we might have weathered this speed bump by improving usability and pricing, boosting marketing, and pivoting to success. But, as is often the case, our “investors” (senior management at the company) were impatient. In the end we eventually decided to cancel the product and redeploy resources to products with better market traction.

This was another important learning: always be aware of your investors’ expectations and their definition of success. For example, if additional investment is contingent on a fast market win, then you must take a more short-term approach compared to the case where you have patient capital that’s willing to back you even if you have to pivot a few times before product/market fit.

Of course, methodologies like Lean Startup will tell you that these problems can be avoided by not spending 2 years building something before you know there will be market traction. This is good advice, and we actually followed it! We built our product hand-in-hand with early adopters, released early code, iterated quickly, etc. But knowing you have a few eager early adopters is *very* different from crossing the chasm to mainstream customers where customer expectations are different.

This was the final important learning: the product required to succeed with early adopters is usually different from the product that mainstream customers want. If you get lucky, mainstream adoption only requires “more of the same”: incrementally adding more features, more reference customers, more documentation, more marketing, etc. But in my doomed product’s case, we weren’t lucky. By over-relying on early adopter feedback I missed a fundamental fact about our market: our early adopters were mainly DevOps people focused on software who wanted to scale their server apps without having to deal with network IT people. But the mass market for our product turned out to be network IT engineers who preferred hardware solutions to messy software. What was a feature (“no hardware!”) for our early adopters turned out to be a fatal bug for the mainstream.

The lesson here: do your homework early about what a “pivot to the mainstream” will require. Don’t just assume you can double-down on your initial customers and everything will work out fine. One way to do this is to interview very large customers, even if you know you won’t be able to sell to them for many years. The purpose of these interviews is to provide an early warning system to understand how mainstream customers differ from your early adopters, and to highlight fatal problems (like our software-vs-hardware issue noted above) that may trip you up when you later want to “cross the chasm”.

All three learnings above have one thing in common: the need to think several years in the future while not neglecting day-to-day execution. Especially when launching a new product or company, it’s important to take a hard-headed look at market trends and to predict what the market is likely to look like when your product and go-to-market efforts are at full strength and you’re winning mainstream customers. Be honest with yourself, your team, and your investors about what it will take to succeed in *that* market, not only the market that exists today.

Epilogue: you’re not doomed to repeat the same mistakes!

A good thing about making mistakes is you can use what you learned to change the future! When I started as Head of Product at Cantaloupe, I kept these lessons in mind:

• Plan for a future market.

• Align with investor expectations.

• Know the needs of the mainstream.

The last lesson was immediately useful. When I joined, our product was popular with early adopters but struggling to win mainstream customers. Remembering my earlier mistake, I went on a long road trip with my new team to interview large customers who weren’t yet in our target market. We learned that software integration hassles were the main obstacle; mainstream customers wanted a seamless, single-vendor offering instead of the patched-together solution of best-of-breed components that our early adopters preferred. (The reason for this was that early adopters often had in-house IT talent, while mainstream customers relied on vendors.) My team absorbed this knowledge and we soon pivoted our product strategy from a “depth-first” model that required integrations to a “breadth” approach that filled in competitive feature gaps and gradually replaced 3rd-party integrations with our own software. This turned out to be the key to winning the mainstream.

A few years later, I used the other two learnings—planning for a long-term future and paying close attention to investor expectations—when our Board started squabbling about whether to do another funding round and “swing for the fences” or to buckle down and achieve profitability. Hiring was frozen while our investors tried (for years!) to work out their differences. Meanwhile, product velocity was slowing and we desperately needed more engineering headcount. Using the lessons from my earlier mistake, I didn’t simply walk into the next Board meeting and ask for more headcount. It would have been shot down. Instead, I carefully built an investor-friendly (quantitative, graphical, and simple), dollars-and-cents business case using analysis of 1500+ JIRA tickets to project our likely roadmap capacity in three different engineering headcount scenarios. By showing the Board the likely outcome of this quarter’s hiring decisions 18-24 months later, we got approval to hire despite the overall headcount freeze.

Obviously, it’s better to avoid making mistakes the first time. But if you do screw up, it’s helpful—at least it’s been helpful for me!—to take an honest look at what you did wrong, and to mine that experience for ways to make a better future.

Are you a CEO who’s hiring your first Head of Product? Have you just accepted a Head of Product role reporting to a CEO who’s obsessed with great products? Don’t worry! In theory this could be a recipe for conflict or butting heads, but in practice I’ve found it to be a huge net positive if you go into it with the right attitude.

When I joined Cantaloupe, I inherited the Head of Product role from the founding CEO. I ended up working for my boss @mdeeps for almost 7 years as we grew from an early-adopter product to a market leader, and from early market traction to $16M ARR and a 4x-to-investors exit. Here’s some advice about the CEO & Head of Product partnership and how to make it successful.

It’s important to recognize *why* a product-focused CEO—who’s typically led Product since the company was founded—now wants to hire a Head of Product. The usual reason: the CEO has gotten so busy that they can’t do a good job as CEO while running Product too. But although the CEO realizes that they need help, they’re also wistful and a little concerned about losing control over the product. They want to continue having a lot of influence on the product, even if they don’t have time to drive it day-to-day.

So with that in mind, the perfect candidate in this role is someone who:

• a) Is better at PM in general (strategy, roadmapping, project management, hiring PMs, collaborating with engineers, interaction design, communication, etc.) than the CEO.

AND

• b) Is eager to incorporate the CEOs ideas and feedback into the product, especially for the first year or so when the new Head of Product is just learning the space.

Both of these are crucial. If you don’t know more about running a PM team than the CEO does, then your CEO will be thinking “why are you here?” The reason to bring in a Product lead was to lighten the CEO’s load. If you can’t run Product more effectively than the CEO can, then you’re not lightening their load and you won’t last long.

But the second piece is vitally important too. If you’re working for a CEO with strong opinions about the product—and a multi-year track record of managing that product, or else you wouldn’t have taken the job, right?—then don’t expect to be a Steve Jobs character who always knows what’s best and tells everyone else to bugger off. Instead, you need to buy into the CEO’s vision for the product. You need to think of your job as improving and extending that vision, not fixing it or re-inventing it. That doesn’t mean you should be a pushover either. Part of your job will always be defending the company against bad or mediocre product ideas, even if they come from the CEO. But a prerequisite for Head of Product success is being on the same high-level wavelength about where the product should go. If you don’t buy into the CEO’s vision and have a good mind-meld vibe with them during the interview process, then don’t take the job.

But if you have both (a) and (b), then it can be a great experience for both of you. You get to leverage the CEO’s industry knowledge and bottomless well of ideas, which will make you come up to speed a lot faster than if you had to build a product strategy from scratch. You’ll also have a senior partner to bounce ideas off of and to brainstorm with. Especially if you’ve inherited a junior team (or no team!) this informal collaboration can make a huge positive difference in the quality of features you’ll ship.

On the CEO’s end, the biggest benefit is that they can finally start to relax about the product once they know it’s in good hands. It’s impossible to overstate how much CEOs worry about everything. If you can reduce their worry load, that can have a big positive impact on a product-focused CEO’s ability to concentrate on everything else that needs attention. You’ll also help on a practical level because there are typically only a few people in a small company who can stand in for the CEO as a conference speaker, in customer/partner meetings, or anywhere else that a senior person with good communication skills is needed. Finally, just like grandparents love playing with babies before handing them off to mom or dad for a diaper change, having you around means that the CEO can still do fun Product work like brainstorming features while avoiding the less-fun parts like writing specs or bug triage.

Just make sure that you’re always checking in with the CEO to make sure that they’re having the right (from their perspective!) level of input into the product. This might mean spending most of your 1:1 time brainstorming feature ideas. It might be sending the CEO links to early code and getting their feedback. It might be sharing customer insights. It might be interesting data or metrics. And so on. Figure out how your CEO wants to be involved and let them be involved.

Sometimes a CEO might have too much input. You might think that they’re micro-managing. Relax, it’ll pass. The CEO has spent years thinking about this product. Now someone else is driving. This adjustment might take a while. Let it happen. If the CEO is randomizing your team with too much input, then that’s probably a sign you’re not proactively involving them and/or not spending enough 1:1 time with them. If the CEO trusts *you* to make the right thing happen, then they’ll leave your team alone.

What will usually happen is that over time your CEO will get less involved in the product. Not because they don’t care; they still do! But the CEO role—with its core duties of managing VPs, “managing” the Board and investors, recruiting constantly, and ensuring the company stays solvent—is a more-than-full-time job. Most CEOs are too busy to spend much time on anything that someone else is handling well. So just go handle it well.

P.S. - Sales-focused leaders (like our CEO when I was at Splunk) and Engineering-focused leaders (like multiple managers I had at Microsoft) are also great! If I have time, I’ll do another post later with tips for making those relationships run smoothly too.

A common problem in SaaS is when big customers or sales prospects demand that you build specific features, often with the implicit or explicit threat that they won’t buy or renew without those features.

These requests put PMs in a tough spot: you don’t want your company to become the outsourced development shop for a few customers’ idiosyncratic workflows, but you also don’t want to offend a good customer and don’t want to be responsible for your company losing short-term revenue. And you don’t want to lose the confidence of your Sales team or your CEO who’re on the hook for that short-term revenue! What to do?

One approach to these requests is to take a Steve Jobs approach and flatly refuse. We’re all familiar with entrepreneurs who proudly ignore customer requests, using justifications like this:

This meme has a core of truth: most customers have short-sighted desires that won’t help their (or your!) company’s best interests in the long run. Building exactly what customers ask for will incrementally drive your company into irrelevance because you’ll never be able to carve out enough engineering time to work on truly transformative progress that few customers ever ask for.

But they’re still your customers. You should love them! Even if you don’t love them, they pay the bills. It’s not your job to “take orders” for features, but it *is* your job to convince your customers that your roadmap is a good solution for their company. Doing this convincing requires more flexibility and EQ than a reflexive “no”.

When I led Product at Cantaloupe, we had a lot of large, opinionated customers who were never shy about telling us what they wanted. Feature requests came up in many renewal discussions. Every year we had big customers threaten to leave over a feature they wanted ASAP. We sometimes had customers send us specs and screenshots of features they wanted us to build! And of course our Support and Customer Success teams were deluged on a daily basis with feature requests—many of which were too obscure or off-target to make it onto our roadmap.

Over many years of practice, our team got *very* good at handling these situations. Below I’ll share a few of the techniques we used to keep customers happy while keeping the roadmap mostly on-track.

To avoid a “sales-defined product roadmap”, build mutual trust and respect with your Sales team

PMs should be working hand-in-hand with Sales to understand feature requests and to figure out the right way to respond to those requests. But in some companies, the Product and Sales relationship is dysfunctional. For example, salespeople may commit to features and expect Product and Engineering to deliver them.

As a PM, you don’t want Sales free-lancing and defining the product roadmap by promising features to customers. But you also need to understand where Sales is coming from. If a feature request is important enough to get on your radar, there’s a salesperson who’s working with that customer whose commission (and maybe their job too!) might be at stake if that feature request isn’t handled well. So it helps to be empathetic and creative. Your goal is to help Sales to stop promising features by showing them a better way to achieve what they want (to close deals) without always needing to promise features to get deals done.

I’ve found the best way to achieve this is to work in parallel. On one track, improve communication and trust and help the Sales team see you as a resource that can help them close more business and to avoid deals that will fall apart later. On the other track, you must communicate clear guidelines about how Sales should talk about the future with prospects. The two tracks reinforce each other; if Sales sees you as a benefit, then you’ll have a much easier time getting them to stop promising.

Here’s a few practices that worked for us:

• PMs should attend Sales meetings at least monthly. The more the Sales team sees you, the more you’ll hear in advance about deals with roadmap impact. Deals for medium-size and enterprise customers usually take 3+ months to close, so that gives you time to hear about it if you’re in the Zoom or the room. A good excuse to attend is to ask what feature requests, competitive issues, and customer complaints they’ve been hearing. Also you can talk through what’s in the next release or discuss what’s just shipped.

• Tag along on sales calls. Especially with large/enterprise customers, it can really help the salesperson if a sales-savvy PM can attend to give demos, answer questions, and otherwise show the customer that they’re important enough to justify “a product executive from HQ” being on the call or in-person visit. Some salespeople can be hesitant, thinking the PM will screw up their deal. It helps to find a salesperson who isn’t hesitant, and to help her close a huge deal. Others will notice. The more you’re viewed as a close-assister, the more Sales friends you’ll have. These calls and visits are also great opportunities to talk with customers, to gather user feedback, to extract competitive intelligence, etc.

• Don’t write features and dates into contracts! Work with your sales team to never put specific feature deliverables (and, especially, dates for those) into written or even verbal commitments. Doing this puts cashflow at risk and removes roadmap flexibility which may be needed to close other deals. Also, I’ve also been told that an accounting rule prevents recognizing revenue from contracts that demand future deliverables. Don’t do this! Instead, work with Sales to come up with alternatives. One thing that worked for us was promising a customer that we’d work on their request “first”, meaning it’d be the top priority of our team starting X weeks from now. Or that it’d be our third priority after feature A and B (that the customer also wanted) were shipped.

• PMs should encourage (and later, require!) salespeople to call them before promising unreleased features to a customer. This is the main thing you want from Sales: before promising anything that hasn’t shipped yet, they must check with you first. Over time, try to make it a rule. Caveat: if you always say no, they won’t call you! Try to figure out how to help the salesperson accomplish what they want, which is to close the deal. Finding creative ways to help them achieve that—and to avoid saying no—is what the rest of this post is about.

Tips for Handling Feature Requests from Important Customers

Once you’re on the same page with Sales, now you need to figure out what to do about the customer’s request. Here’s some techniques that have worked well for me and my teams in the past.

• Generalize features. You can often take "custom" requests from top customers and generalize them into something that applies to a wider customer base. If you have to do something for your largest customer, try really hard to figure out how to make it add value for everyone else. If your top dog customer pushes back on generalizing, it often helps to point out that features built for one customer never work as well as features built for everyone that have more eyeballs ensuring quality and more users clamoring for improvements. For this reason, smart customers often won't want custom features—as long as you gently educate them about why custom features are bad for them too.

• Know your customer directly, and especially their decision-makers. You should be in regular, real-time (calls and ideally visits) contact with your top customers. Don't wait until they call support to complain! You should know what keeps them up at night. Get to know the decision-makers who actually drive upgrades and cause churn at that customer. Learn their top business problems, not just their team's minor gripes with your product this week. Know how you can help make your champion look smart and get promoted!

• Solve problems, not support tickets. Uplevel the discussion with the customer. Understand why they're asking for a particular feature or report or change. See if they've tried other ways to solve the problem. Understand the business process that led to the support ticket. Understand if this is a really big deal or only a minor annoyance. If you have a feature in the roadmap that may address the problem, show them a demo or screenshot, ask for their feedback, whatever you can do to align this incremental custom request with a larger and more generalized thing.

• Code as last resort. As technology experts, we instinctually think that technology is the best solution. But often it's not! The answer to the customer's problem might not require changing the product. It might be a blog post, or help video, or FAQ, or other cheaper artifact. It might be training a customer yourself about how to use an advanced feature. Or training your support team. Your development team will love you when you take work off their plate, and your customers will love you if you deliver faster solutions that don't require a product release.

• Coalesce and stack-rank requests from different stakeholders at the same customer. It’s common to get requests from many different people at the same large customer. Each of them usually thinks that their request is the most important. A technique that worked well for us at Cantaloupe was to ask the business decision-maker at these customers to choose a single point of contact on their staff who’d prepare a single, prioritized list of all of the company’s requests. This forced different people at the same customer to work together and come to consensus. When working with our most strategic and/or challenging customers, this simple process had many benefits:

  • Helps the customer understand why you can't do everything at once. Avoids “I want it all and I want it now” noise because it’s obvious even to non-PMs that you’ll work on the list in order.

  • Keeps you out of internal fights among different stakeholders at the customer. If Steve in Accounting team wants feature X but Theresa from IT department wants Y, requiring a stack-ranked list puts the onus on the customer’s senior execs—not you!— to decide whether Steve’s or Theresa’s asks are more important to them.

  • Avoids you having to track one-off requests from random people in the customer’s company. All feedback must get funneled to one customer contact who might say “no” or “we already have that” or otherwise avoids your team wasting time documenting a low-priority or unnecessary request.

  • Keeps things focused on items at the top of the list. Lower-priority needs might even go away by the time you are done with the top items, which saves your time without the customer feeling like you’re stalling them.

  • Note: even if there’s no common executive at the customer who can enforce priorities, you can invite your stakeholders at that customer to a conf call or in-person meeting and facilitate the stack-ranking. These meetings can be magic; they often lead to fast consensus because no one wants to beat up their co-workers in public like they beat you up privately!

• Proactively meet with your largest customers about their requests. At Cantaloupe, whenever we met with a big customer to review their prioritized list, we transferred their list to a Google Sheet in a standard format and gave the customer read-only access. Then, for the largest customers, we’d meet with them 2-4 times per year to review progress on their list and to make changes if needed. Not all customers got this non-scalable experience, but even if you have hundreds of customers you can probably afford this process for your top 10 most-strategic accounts. A nice side effect of recurring reviews is that customers saved up their feedback and complaints for the meetings, instead of bombarding our team with one-off requests. Another benefit is that these meetings were a great opportunity to connect with customers to ask about what’s changed in their business, about what our competitors are doing, etc.

• Always ask how new requests should be prioritized vs. old ones. Whenever you get a new request from a customer with multiple outstanding requests, always ask how the new arrival should be prioritized relative to the old ones. If the new thing isn’t at the top of the list, you’re off the hook until the top one ships, because of course the customer won’t want you to stop working on their top priority! 😄

• Include your roadmap (as a list, not swimlanes with dates!) in prioritization discussions with trusted customers. I try not to have a prioritization discussion with a big customer about their incremental requests without discussing the whole roadmap too. If there were items on the roadmap that the customer wants, we’d ask them how those items should be prioritized relative to the customer’s specific asks. Sometimes our top roadmap items would be ranked ahead of all custom asks, which meant we could deliver the customer’s top asks *and* our own top priorities at the same time. Seeing the full roadmap also helps the customer internalize that if they get 10 minor incremental fixes, then it'll add months of delays to get that cool feature they've been drooling to get since they signed up a year ago!

  • Tip: don’t frame these discussions as “here’s our roadmap” but rather translate the roadmap to a simple prioritized list and say “here’s a list of features that other customers have asked for and which we’re considering working on next” which lowers the stakes because you’re not actually committing to anything.

• Get your customers together! If you can, get your customers together in one place (physically or virtually) for an "advisors group" and get them to prioritize your roadmap (per above: as a ranked list, not swimlanes and dates!) along with any incremental improvements the group asks for. In other words, take the single-customer process described above and scale it to a group of your top strategic customers. Groups of senior decision-makers often do a great job at helping you identify the most important things. Also they tend to be focused, because they don’t want to look dumb in front of their peers by focusing on trivial stuff or bad ideas. Plus, each individual customer may want to make your company their servant, but the group overall more than anything wants you to be successful and to stay in business, otherwise everyone loses. Some industries are too competitive or too busy to make this work. But when it works, your customers become a team of cheerleaders rooting for your success. Hint: if it's in-person, you'll need to pay for hotel & group meals. Don't be cheap!

• Show progress. If you can't deliver all 10 things the customer asks for, deliver one this quarter and tell them about it. Deliver one next quarter and tell them about it. And so on. Any time you have good news about anything they want moving through the release, let them know. Humans love progress bars vastly more than a spinning wait cursor or blank screen. Be a progress bar!

• Prove that you understand how important the problem is, even if you can't solve it yet. How you communicate with and relate with a customer often matters as much as what and when you deliver. An enterprise customer has often made a career-risking bet on your product. The biggest fear of your customer isn't that you'll be late. It's that you'll ignore them and *never* solve the problems you promised you would—just like every other B2B tech company since the dawn of time. If you can't solve the problem right now, at least spend the time with the customer so that they know that you understand the problem and really care about will solving it in the future. SaaS is not about today's tech, it's about the promise of a better future. Make them believe!

• Propose partial solutions. Sometimes a part of a customer’s request is compatible with your priorities, but the remainder isn’t. If that happens, consider splitting the ask: deliver the strategic part yourself and leave the rest for manual work or a partner to handle. For example, I worked with a large customer who wanted direct access to our production database in order to extract data every day into a data warehouse. This was not OK for us, because it’d introduce a hard dependency between our frequently-changing DB schema and would restrict future innovation. But they were adamant. We compromised on a partial solution: an API layer over our existing custom-report feature. The customer built custom reports to extract the data they wanted, and then could use the new API to pull data on a regular basis. The customer’s technical team hated this idea because it was hacky and caused more work for them, but the customer’s management team overrode those concerns because they felt that a “good enough” partial solution was better than nothing.

• Leverage decision-maker vs. team mismatch. The anecdote above about decision-makers overriding their own team is actually pretty common. A customer’s decision-maker(s) often have different priorities from the folks on their team. People on the team are usually most focused on making their jobs easier and boosting their personal KPIs. But decision-makers are typically focused on top-level business results, so they’re sometimes willing to make decisions that will make their team’s life more difficult in exchange for saving money or time, or to support some other higher-priority initiative. This usually means that decision-makers can be more flexible than the people who work for them. As PMs we can (carefully! politely!) leverage this to uplevel the often-myopic feedback you’ll get from power users who don’t sign checks.

• Maybe: empower partners and developers to fill feature gaps. Mature SaaS companies like Salesforce don’t build every customer request either. Instead, they put an API surface on their products and nurture a partner ecosystem to build what the core product lacks. If your product has very clear integration cases (like the “get output of a custom report” example noted above) then building an API makes sense. Just be careful: changing API behavior later is much more painful for customers than changing UI because retraining humans is usually cheaper and faster than getting code changed to respond to your API changes. What usually happens is that you’re stuck supporting the “V1” API for many years after “V2” ships. Also, supporting developers often requires a different set of people and skills than supporting GUI users. So be open to API-ification to reduce pressure on custom feature requests, but be aware it’s not a panacea and might make things worse. Before adding your first API, talk with someone who’s done it before and get their advice!

• Charge a lot to influence the roadmap. Commonly, requests from customers are already on the roadmap. This is a great opportunity for Sales to get additional revenue for work your team was going to do anyways! For example, if we were going to build feature Z in 6 months, but a big customer is willing to sign up but needs Z sooner, then I’m usually open to rearranging the roadmap (e.g. ship Z in 3 months) to help the deal close. My main ask for Sales is to have the customer understand that the privilege of getting something on the roadmap is rare and *very* expensive. In addition to preventing customers from demanding free roadmap influence later, a high price also differentiates customers who *really* want a feature vs. those who can live without it. The latter deals are cheaper for the company (no new R&D!) and often close quicker instead of waiting for the features to ship.

If all else fails, say “no” clearly and directly (but let Sales say it)

Sometimes a customer’s requests are so specific-to-them and expensive that there’s no way to justify the large engineering investment and opportunity cost (revenue you could get from other customers using the same engineering investment). When that happens, your company’s best bet is to be honest with the customer about why you can’t fulfill their requests. Don’t delay or hedge because the customer will just get angrier. Your customers are businesses too; they may not agree with your priorities but they will probably understand.

Note that delivering bad news to customers is usually *not* PM’s job, because it may have revenue consequences. Instead, bring someone senior on the Sales side to lead that discussion to deliver the bad news and deal with the blowback. You should attend if they want you there, but ultimately it’s their quota and job on the line, so you should follow their lead.

Another reason why it’s good to let Sales break bad news is that good salespeople can turn lemons into lemonade. For example, we once had a very large customer who made a long list of feature requests and promised to churn if we didn’t build them. The asks were specific to that customer and not generalizable, and the total cost of building them would be 12+ months of our total roadmap capacity. So we had to say no. But instead of simply divorcing the customer and losing all that revenue, this Sales genius figured out a way to keep (and even grow!) part of their business. For the rest, he offered free consulting time to migrate part of their business to our biggest competitor. The customer won because they got a faster, cheaper path to tech that they believed would better meet their needs, while not incurring the hassle and expense of ripping out all our tech. We won because we retained a lot of recurring revenue, and because the customer felt he’d been treated fairly so didn’t bad-mouth us to others. And as an added bonus, our top competitor acquired a really demanding customer who’d tie up their engineers for a long time with custom requests!

After interviewing a few hundred Product Manager candidates over the years, I’ve come to believe that interviews should approximate actual work tasks and conditions. The more you test candidates’ ability to do everyday work, the more you’ll hire people who can succeed at the everyday job. For example, I don’t use “puzzle” questions like “How many ping-pong balls can fit into a 747?” or “Convince me to buy an egg” because they’re too abstract and unrealistic compared to actual PM work.

But pretty soon I’m going to start the long process of finding a startup to join next. For the first time in many years, I’ll be answering PM interview questions as opposed to asking them. So I’ve had to bone up on 2021 fashions for PM interviews. From my perspective as an interviewer, some of these questions look more useful than others. But one type seems really dubious: “behavioral” questions like the ones below that take the form “Tell me about a time when…”

• Tell me about a time when you disagreed with a decision of your manager.

• Tell me about a time when your team couldn’t meet a deadline.

• Tell me about a time when someone on your team was under-performing.

• Tell me about a time when you used metrics or data to improve a product.

• Tell me about a time when a customer asked for a feature you thought was a bad idea.

These questions *seem* like they should be reflective of actual PM work because they’re talking about actual PM work. But in my experience, talking about a thing and doing a thing require different skills—it’s easy to end up with a good storyteller who can’t do the job well.

I’m not the only one concerned about these questions. According to Glassdoor, these questions are biased against diverse candidates. According to Harvard Business Review, “Be Wary of Historical Questions”. According to Wharton Business School professor Adam Grant:

They're too easy to game--you end up hiring the candidate who's the best talker, not the best contributor.… They're not tailored to your organization or the job--they're stuck in what applicants have encountered in the past, not what they're going to do for you in the future.

Google search users also have an opinion:

Twitter apparently agrees. In a fun coincidence, the 11th most liked job-interview-related tweet of all time was just posted yesterday.

Here’s what to expect in the rest of this post:

• Alternative questions to validate soft skills without “Tell me about a time when…”

• Details about my specific concerns with storytelling questions

• Ideas for going beyond “questions” to also include non-question activities that better approximate real PM work.

• How the neuroscience of human memory intersects with interview questions.

Alternative questions with more context

There are many other ways to test the soft skills of PM candidates besides “Tell me about a time…” questions! My preference: ask about real but anonymized interpersonal situations that the team is currently experiencing (or has experienced but are still relevant) and ask the candidate how they’d help.

Providing context gives more flexibility to the candidate to answer in the most intuitive way for them. Folks with good episodic memory can share anecdotes. Folks like me who like discovery and brainstorming can do that. Folks who focus on process and structure can talk about how they’ve engineered ways to prevent problems in the first place. And so on. 

Another reason that real situations are helpful: when the candidate asks clarifying questions you won’t have to invent facts on the fly.

Below are example questions that I might ask a SaaS VP Product candidate. They’re adapted from my own experience, with details changed to protect the innocent… or guilty! ;-)

IMPORTANT: Don’t use my questions! They’re from *my* history, and are relevant to SaaS VP Product positions that I specialize in. For your interviews, use questions based on challenges at *your* company and roles you’re recruiting for!

Alternatives to: “Tell me about a time when you disagreed with a decision of your manager.”

• “You’ve just finished a refresh of the product roadmap. It’s been approved by the exec team and been vetted with a few trusted customers. You’re planning to present it to the whole company at an all-hands meeting tomorrow. But your manager, who just got back from customer road trip, emails you asking to remove the top two features on the roadmap and replace them with other features you haven’t researched nor costed. What do you do?”

• “Your industry’s annual conference is coming up in a month. Your manager is pushing you to release a big new feature in time for the conference. You’re pretty confident that the feature won’t be ready in time, but when you told him your concerns, he said ‘just ship it anyway, we can clean up afterwards’ and left no wiggle room for discussion. When you DM-ed your Engineering counterpart what your manager said, he said “no” and stopped answering your texts or emails. What do you do?”

• “Your CEO is sometimes a micro-manager on design issues. One of the designers on your team is having a really hard time with this, specifically with the CEO’s focus on relatively minor design details like specific colors or fonts. You believe your designer is correct that these relatively minor decisions should be left up to the Design team, but you also agree with the CEO that this designer’s visual design instincts aren’t as polished as their overall UX skills. What do you do?”

Alternatives to: “Tell me about a time when your team couldn’t meet a deadline”

• “Based on earlier guidance from you, Sales promised several big customers that a particular feature would ship in April. At the time you were very confident about that estimate. But your engineering lead just told you that a technical issue was uncovered and the feature can’t be finished until July: 3 months later than expected. What do you do?”

• “Your CEO told you that she’s concerned that features are being shipped at a slower pace than last year, even though the PM and Eng teams have grown by 2x during that time. You agree with her, although you don’t have any hard data to prove this assumption. What do you do?”

• “Your QA team just uncovered a serious scalability issue that will cause your service to completely fail when concurrent users grow by about 40%, which is projected to happen in about 6 months. Fixing the problem will require about one-fourth of total roadmap capacity for the year. You know that several huge sales deals are blocked on features that you’re planning to ship this year. What do you do?”

Alternatives to: “Tell me about a time when someone on your team was under-performing.”

• “One of the engineers you work with seems to frequently make mistakes that lead to customer-reported bugs. You’ve mentioned this problem to the Engineering lead and she said she’d look into it, although you haven’t seen any improvement. Now this engineer has been assigned to build a high-priority, technically-challenging feature. What do you do?”

• “Developers at your company are complaining that one of the PMs on your team writes specs without enough detail. How do you address the issue?”

• “The Product Marketing team at your company has been struggling to support the fast pace of product updates. For example, press releases are full of sloppy mistakes and clumsy messaging; the corporate website hasn’t been updated in a year despite a big shift in product strategy; and the latest content-marketing blog posts aren’t aligned with what you believe are customers’ top interests and concerns. What do you do?”

Alternatives to: “Tell me about a time when you used metrics or data to improve a product.”

• “After steadily climbing for two years, your company’s NPS score declined by 10 points in the last month. There have been no major changes in pricing or product features, no major outages, nor any other immediately-obvious explanation for the change. What do you do?”

• “Our company’s north-star metric is repeat usage: how many people use the product every week. The cohort of customers who signed up last year continues to improve in this metric. But the cohort of customers who signed up this year has been flat. What do you do?”

• “Our customers in Mexico are churning 3x as much as customers in other geographies. What do you do?”

Alternatives to: “Tell me about a time when a customer asked for a feature you thought was a bad idea.”

• “Your biggest SaaS customer—responsible for 15% of revenue!—is demanding that you add a custom integration with their company’s bespoke inventory software. No other customer uses this same software. What do you do?”

• “Your engineering team wants to stop supporting iOS 12 and below, in order to use APIs introduced in iOS 13 that will reduce the cost of new mobile features by about one-third. Only 2% of users use iOS 12 or below, but your largest customer—responsible for 15% of revenue!—has 50 field techs who use your app on old-model iPads which can’t be upgraded past iOS 12. What do you do?”

• “Your top competitor just released a new reporting feature that has been well-received in the market. Two large customers have told your salespeople that they are considering switching to that competitor in order to take advantage of this feature. You’re in the middle of a yearlong overhaul of your current reporting features which would make it much easier to deliver features like your competitor’s. But Sales (and the CEO, and your contacts at those customers) are pressuring you to implement this feature on your old reporting system, which will push back the entire roadmap by 3 calendar months and result in 4 engineers spending 3 months on code that will be mostly thrown away when the new reporting engine ships. What do you do?”

For all these alternative questions, here’s what to look for:

• The candidate shouldn’t freeze like a deer in the headlights or otherwise show that they’d struggle to face a situation like this.

• The candidate should ask thoughtful clarifying questions before launching into a solution.

• Good candidates will push back on some requirements or otherwise show that they’re creative about finding win-win alternatives that achieve similar goals via easier means. But they won’t push back forever against an immovable object. Instead they’ll often try to get around the objection in a creative way

• When candidates weave in anecdotes about how they’ve solved similar problems in the past, they should be relevant to the context you’ve provided.

• It’s often helpful for interviewers to introduce new information into the question midway in order to make the candidate’s initial solution unworkable. Good candidates will appropriately adapt to the new information. Bad candidates will keep going on their initial idea without stepping back to consider if it’s still appropriate.

• Candidates should react well to being told that a particular proposed solution won’t work. “Well” usually means “curious”—instead of immediately pushing back or giving up quickly. The best candidates will dig in to understand *why* it won’t work, and will use that additional information to improve their proposed solution.

• Good candidates will be comfortable talking about and managing interpersonal dynamics. A red flag for me is a candidate who keeps turning the discussion back to features and metrics, even after I nudge them to talk about people and emotions. I sometimes test this by role-playing a difficult manager, customer, or team-mate and observe how the candidate treats me. Are they warm, collaborative, and steadily pushing for a win-win outcome? Or are they condescending, inflexible (or a pushover), or uncreative in coming up with reasonable compromises?

• The best candidates will involve the interviewer in figuring out the solution, so that it feels more like a natural brainstorm session than a Q&A.

These questions and techniques are forward-looking and context-sensitive. They invite the candidate to demonstrate discovery and collaboration skills. They can introduce unpredictable ambiguity and change. In other words, they’re like actual PM work that the candidate will be doing if they get the job.

Why are anecdotal storytelling questions bad?

A few concerns with “Tell me about a time when…” questions:

• Too generic / lacking context. Challenges vary by company. One team may constantly squabble while another is too conflict-avoidant. One team’s PMs may write sloppy specs, while another’s are too prescriptive. And so on. But “tell me about a time…” questions are generic. If a candidate picks pick the wrong anecdote, it can look like they don’t have experience with the problems that matter most to your company or team. Good PMs can adapt their problem-solving skills to the situation at hand, but they need context to know what the problem is! For example, instead of “Tell me about a time when there was conflict on your team” consider this instead: “Frequent engineer vs. designer arguments are getting out of hand on one team. How could you help?”

• Wastes scarce interview time. Interviews are short, so interview time is precious. But when telling stories, the candidate may have to burn a few minutes providing context to the interviewer about the candidate’s company/product/team so that the story will make sense. This is especially true for candidates who work on obscure products or industries that require more explanation. However, if the interviewer supplies the anecdote, then it’s up to the candidate to interrogate the interviewer to discover context… which is just what real PMs must do every day! Using the “engineer vs. designer arguing” example described above, the candidate can ask “What do they usually argue about? Do their arguments usually lead to compromises, or does one side usually win? Is arguing limited to specific people, or is it team-vs-team?” and other questions that reveal to the interviewer how that candidate approaches interpersonal problem-solving. Instead of wasting scarce time learning about the candidate’s workplace drama, the interviewer can verify an important PM skill: asking good questions and synthesizing answers into a better solution.

• Game-able / too sensitive to preparation. I’ve had a few occasions to answer these kinds of questions as a candidate, and when I had a suitable anecdote pre-prepared with talking points, my answer was clear, concise, and convincing. This was true even in areas where I know I’m relatively weak, because like most PMs I’m pretty good at narrative storytelling. It was very easy to fake competence. But when none of my canned anecdotes fit and I had to pick a story on the fly, my answers were rambling even in areas where I know I’m solid. The format seemed to be testing interview prep more than PM skills.

• Unrelated to the company’s product & industry. By focusing solely on the candidate’s history, interviewers can’t test my ability to understand or solve problems with *their* product or industry. This is odd, especially for PM roles expected to own the product roadmap. As a candidate, it’d make me worry about screening for other roles besides mine; would my potential colleagues have been vetted for their ability to solve this industry’s problems?

• Suggests a dysfunctional culture. So many of these questions focus on conflict or difficulty. It would make me wonder whether this company was an interpersonal mess!

• No collaboration. Solving most real-world problems requires teamwork, but story-telling questions leave little space to collaborate with the interviewer. Problem-solving questions, however, encourage back-and-forth with the interviewer to clarify the problem and iterate on a solution. That’s better.

• Worse with experience. If you’d asked 16-year-old me “Tell me about a time you drove on the freeway” I’d tell a detailed and compelling story of my first freeway drive because it was just months earlier. Ask me the same question today and you’d either get a blank look, or a story about a flaming car, a terrifying accident, or something else that was unusual enough to stand out from thousands of other freeway drives. Will those unusual stories really help an interviewer know whether I’d be a good delivery driver? The same is true for PMs. Ask a brand-new PM “tell me about a time you handled inter-group conflict” and there may be only one or two occasions to choose from. But an experienced PM may only remember unusual situations that aren’t representative of everyday performance. A better approach is to generalize, e.g. “How do you handle inter-group conflict?” which lets inexperienced candidates narrate their 1-2 times doing it, while senior candidates can talk about general approaches they’ve learned by trial and error after doing it hundreds of times.

• Unrealistic. Summarizing the concerns above, “Tell me about a time when…” questions are not like actual PM work. Real PM work generally involves gathering and synthesizing information, solving problems with colleagues, resolving disagreements, building team cohesion, helping teams make tough decisions, and clearly communicating results to multiple audiences. In my experience, *talking* about doing those things requires different skills than actually *doing* those things. When interviewing PMs, it’s better to focus on “doing”.

Company context isn’t just for soft skills

Realistic, context-ful questions are also helpful for “hard” skill interviews focused on product strategy, business issues, UX design, etc. When I interview at a company, I usually spend 2-3 days learning all that I can about that company, its industry, and its competition. I search the web to find users’ opinions about the company and its products. I download and use its product (if possible), and ideally its top competitors too. I try to find and interview a few of its customers (if possible) and get their opinions. I write up prioritized feedback about the product. And when I’m an interviewer, I expect that every candidate should do this… although maybe not to the same obsessive extent that I do. ;-)

Candidates won’t know a lot of insider details after a weekend of research, but being able to quickly research products and industries and to speak intelligently about the results is something that PMs do frequently at work. So in an interview, I think it’s good to ask the candidate the same kinds of tough questions you’d ask them if they were already working there. For example:

• Here’s a screenshot of a page in our product. How would you improve it?

• Imagine you’re in charge of the Birthdays feature at Facebook. What would you do to make it better? (This is a real Facebook PM interview question, BTW.)

• What did you think of our product? How would you improve it?

• We’re trying to decide if we should focus more on Enterprise or continue our SMB-centric strategy. What do you think?

• A big trend in our industry is XXXXX. What do you think of this?

• Our competitor XXXX has been offering our customers to buy out their current contracts if they’ll switch to the competitor’s product. How should we react?

• Imagine we could buy our competitor XXXX for $50M. Should we do it?

Like with soft-skill questions, don’t copy my questions above! You should pick your own that match the context of your company and the position you’re interviewing for. It’s also OK to ask “stretch” questions, because you want to hire people who are capable of thinking about strategy beyond their initial position.

A big caveat: don’t judge candidates’ answers using the same yardstick you’d use for existing employees. Candidates will make incorrect assumptions. They will suggest ideas that you’ve previously considered and dismissed. They’ll be completely unaware of important details. This is OK. What you *should* expect is:

• Intelligent questions to fill in gaps in their knowledge

• Self-awareness of what they know vs. don’t know

• Curiosity—not hostility, persistence, or resignation— if you tell them their idea is off-base

• Use of analogies or otherwise bringing in knowledge from outside your industry

• They teach you something interesting about your product, company, or industry

• Insightful feedback about the new-user experience (if they used your product)

A final note: a context-ful approach can also impress candidates because you’re treating them like colleagues, not like test subjects in a psychology experiment. For example, a PM friend of mine shared that context-sensitive interview questions actually helped him decide on his current company:

PM interviews beyond “questions”

Continuing on the theme of making interviews more like real work, keep in mind that “questions” aren’t the only thing you can do when interviewing a candidate. Here’s a few ways to supplement questions with more-realistic work tasks:

Ask for written work. I’ve been burned in the past by candidates who solve problems well in interviews but have trouble turning high-level solutions into more precise written formats that engineers and executives need. I now always ask candidates for examples of their written work, typically one for a technical audience (like a spec or PRD) and one for a non-technical audience (like a conference presentation or competitive analysis). It’s helpful is to ask for these samples *before* scheduling a full round of interviews with the team. Then if the written work isn’t good, you don’t need waste the team’s time on candidates who won’t work out.

Do a team brainstorm. Instead of a group interview where multiple people each ask one question in a rushed interview, consider a group brainstorm session where the group needs to solve a problem and the candidate is expected to help. Send out the topic in advance so the candidate can prepare, and then the candidate can spend an hour or so with the team and hash out a solution.

Present to the team. If you want to test a PMs ability to connect with an audience, try having her present something to your team. It could be the “work product” above or the output of the “team brainstorm” above. Or it could be a topic of the candidate’s choosing. I did this once long ago as a candidate (I presented about my favorite books) which was a nice way to get to know the team and vice versa, while also demonstrating competence at 1-to-many communication. Note that “present” isn’t necessarily slideware—it could be whatever format the company prefers.

Send questions in advance. If you’re committed to “Tell me about a time when…” questions, consider sending them in advance. Then the candidate can jog their memory with old emails & docs so they’ll have a more accurate and less long-winded story to tell you. This can also be good for non-behavioral problem-solving questions because no PM is expected to solve complex work problems without thinking about them for a while. Take-home questions aren’t good for generic questions where the candidate can Google for answers on the web, but if you take my advice and tailor questions to your company and team, then this should be a non-issue.

Take-home projects. For senior PM candidates, another approach that can work well is a take-home assignment where the candidate spends a few hours solving a problem or defining a plan or strategy, and then delivers it writing form and/or as a presentation. Some caveats:

• Projects are time-consuming for the candidate, so it’s only appropriate after a successful initial round of interviews with the team.

• It’s best if the output is prescribed, e.g. “a 3-5 slide presentation” or “a 2-3 page narrative”. Ideally, send the PM a sample of the kind of output you’re looking for. Good PMs can quickly adapt how they communicate to whatever format the team prefers. DO NOT make the candidate guess what you like!

• Be careful about using this approach for junior candidates. I’ve seen much Twitter angst where candidates feel used by companies for free labor. DO NOT use the interview process to get free work. It’s a test, not a contract assignment. If you want free work, make it a paid project.

Epilogue: the neuroscience of PM interview questions

While researching this post I fell down a rabbit hole of neuroscience research about human memory. Some of it was relevant to interviewing, so I’ll share a summary here.

Human memory is composed of multiple, somewhat-independent components. For example: “semantic memory” is for recalling facts, names, concepts, or ideas, “episodic memory” is for remembering details about events that happened, while “procedural memory” is the ability to perform complex, pre-learned skills like riding a bike or running an effective meeting.

These memory systems are complimentary but operate somewhat independently. Neuroscientists learned this from people with brain injuries. For example, some patients have episodic memory amnesia (they can’t remember what happened yesterday) but they can still learn new skills like throwing a frisbee which requires building new procedural memories. Even without brain damage, some people are clearly better or worse at some types of memory vs. others. For example, while watching The Last Dance I was amazed at some basketball players’ ability to recall minute details of decades-ago games amid thousands of other games. That’s genius-level episodic memory. On the other hand, we’re all familiar with “absent-minded professor” types who are brilliant but frequently forget mundane stuff.

Circling back to the topic of this post, PMs who have great episodic memory will be better at answering “Tell me about a time when…” questions. PMs with lousy episodic memory will struggle with these questions. But I’m unconvinced that good episodic memory (especially details from years ago) is important for day-to-day PM work. The ability to accurately remember a bug report or customer meeting doesn’t matter much if we have JIRA or detailed meeting notes. Relying on memory might even be worse because, unlike JIRA or meeting notes, memory can’t easily be shared asynchronously with many people.

This comes back to my original thesis: interviews should try to match actual PM activities. Pulling up accurate and notes-free memory of long-ago events doesn’t seem to be a common PM activity, so I’d worry that “Tell me about a time when…” questions are unnecessarily screening out good PMs with bad episodic memory skills.

Epilogue 2: hilarious quote tweets

Many thanks to Daniel Lu, Joshua Herzig-Marx, Dan Duett, and Ankit Raheja for reading an early draft of this post and giving great feedback. The bad parts are all my fault, though. ;-)

A big challenge for many PMs—especially junior product managers—is gaining and keeping the respect of the engineers. A *huge* part of the PM job is making life easier for engineers, and if you’re not making their lives easier then it’s pretty much impossible to succeed as a product manager.

A mistake many PMs make is to assume that engineers won’t respect product managers who don’t have strong technical skills. It (almost) never hurts for PMs to be technically strong, but in my experience it’s actually *non-technical* skills—organizational prowess, customer knowledge, clear communication, etc.—that will make or break the engineer↔️PM working relationship, because engineers primarily look for PMs to do things that engineers can’t or don’t want to do.

The list below summarizes a few relatively non-technical practices that PMs can follow. If you do all of these, you’re likely to win the respect of even the grumpiest engineers.

• (Most Important) Be a customer expert. Become known for deep understanding of your user base. Whenever anyone (engineer, salesperson, support, etc.) has a question about what your users want, you should be able to answer it… or to figure out who can answer it. Spend as much time as possible learning about your customers via visits, surveys, market research, usability testing, A/B tests, etc. If the team knows they can trust your judgement about what the customer wants—and if you can prove it when needed!—then they’re more likely to enthusiastically support the roadmap you come up with.

• Know the business and market. In addition to understanding your company’s customers, you also must know the competition, how products are sold and promoted in your industry, what industry trends are happening, and other details about how to maximize the revenue that your team brings in. You should periodically discuss what you’ve learned (at a high level) with engineers you work with. That way they’ll always know *why* they’re being asked to build all this cool tech.

• Write documents with the right level of detail. Every engineering team has their own preferences for how much detail they need from PM to complete their work. Some teams like only high-level requirements or user stories that they will flesh out on their own. Others like very detailed specs with every UI element and behavior carefully specified. Some like to work directly with designers, others want PM to do that. Some prefer prose, others like numbered bullet points. Some like simple wireframes, while others like more realistic UI mockups. Learn what engineers on your team need to be productive, and give it to them! FWIW, “writes bad specs” (or user stories, requirements, PRDs, etc.) is the #1 complaint that I’ve heard from engineers about PMs.

• Shield your team from randomization. Engineers hate being distracted by 1,001 questions or requests or meetings from marketing, support, sales, execs, end-users, etc. A good PM will figure out how to get all that communication pointed at yourself so you can triage the easy stuff and turn the hard stuff into more efficient formats (e.g. bug reports with clear repro cases, or feature requests with clear business context) so your technical team can focus on building cool tech. Especially important: minimize the number of meetings that you drag engineers to that they didn’t really need to attend.

• Stay ahead of your team. There is, IMHO, no greater process failure for a PM than having your engineering team run out of work to do. You should always try to stay a few weeks ahead of your engineers. You should always have the next sprint’s backlog clean and ready in advance. You should always show up to meetings you accepted. And so on. You’re the PM, so it’s your job to make sure that the trains all run on time. If you find yourself doing your homework in real time (e.g. designing features on-the-fly in a sprint planning meeting) then you’re doing it wrong!

• Avoid throwing away engineers’ work. Engineers hate working hard on projects that never actually get shipped or that don’t get used afterwards. Your goal is to minimize this happening by doing your homework on the business value, costs, risks, etc. for new features. My rule of thumb is that a task shouldn’t make it into a sprint unless I’m at least 95% sure that the feature behind that task will ship, and I’m at least 80% sure that it will be used by a significant portion of target users. If you need to run spikes or experiments to determine user interest, then be explicit with your team that this is a test, which will help avoid grumbling if it doesn’t pan out.

• Take responsibility for problems. Never scapegoat. Never blame engineers for things going wrong. They’re just following the priorities and direction you asked them to, right? If the release took too long, think about and discuss what *you* could have done to reduce scope, to anticipate problems, etc. If the code shipped with too many bugs, think and talk about how you (and the team too) can do better next time. Never, ever throw engineers under the bus, even in private— it will get back to your team and they will shun you. Enthusiastically participate in sprint retrospectives or other post-mortems where you and your team can learn from mistakes.

• Be a highly-responsive “unblocker”. In any complex tech project, engineers will frequently have questions or concerns about even the most simple features. Your job is to get those blocking questions answered as soon as possible so they can finish what they’re working on. Think of yourself as the JIRA of engineers’ questions; it’s not your job to answer all questions yourself but it *is* your job to be the tool that ensures that those questions get answered quickly. Especially important: don’t “go dark”. If you’re traveling or are so busy that you can’t reply, let folks know when you’ll be back online and what they should do if they get blocked while you’re out.

• Be a bidirectional business<->engineering translator. Non-engineers and engineers often struggle to understand each other. As a PM you straddle both worlds, so you’re uniquely positioned to translate engineering communication and terms into language that the rest of the company (and your customers!) will understand. Similarly, engineers will often misinterpret what business folks want. They’ll have a much easier time if you can explain business requirements with enough context and detail that they can see how to write code to satisfy those asks. I’m not saying that engineers should be isolated from the rest of the business, only that helping engineers understand the rest of the business—and vice versa—is partly (mostly?) your responsibility.

• Internally promote your team and their work. It’s your job to let the company know what amazing things engineers are working on. In most companies, most non-technical employees don’t understand exactly what engineers do. So it’s your job to explain why all those expensive engineers deserve those fat paychecks! This can include recognizing specific engineers or teams when a cool feature ships. It can mean explaining a technical improvement in business terms. It can mean inviting engineers to give demos or otherwise get visibility with management. One easy piece of advice: whenever *anyone* compliments you about product changes, you should immediately and publicly call out and compliment the engineers, designers, and others (ideally by name) who built the thing. Don’t let your team feel that you’re taking credit for their work. Instead, your team should think of you as their “agent” who’s always supporting and hyping them within the company.

• Take technical debt seriously. You’ll probably want engineers to spend 100% of their time building new features. Resist this impulse. The team needs to refactor old code, to upgrade tools and platforms, to automate manual tasks, and to fix stuff that customers don’t see but which makes engineers' work much easier. This is called “technical debt.” If you defer this maintenance too long, your team’s productivity and morale will suffer. My suggestion: carve out a percentage of your capacity (sprint points, hours, whatever) and hand that portion over to your engineering team so they can triage engineering debt tasks and work on the ones they think are most important. Ideally, PM should not be involved with this triage—just give your engineering team a consistent, predictable chunk. They’ll do the right thing. In my experience, 20%-30% is probably the right allocation for most SaaS teams, with only occasional exceptions like the sprint before an annual conference or a “tech debt sprint” to tackle big refactors.

• Encourage product feedback. Engineers often have great product ideas but they may not always feel comfortable sharing, so it’s good to encourage engineers to give product feedback and good for you to treat it seriously. Often this is easy and natural during sprint planning or spec review meetings, because you can ask for concerns or suggestions with the feature while you’re describing it to the team. The key is to be proactive about asking for feedback, because many engineers can be shy and may not think you will listen nor care. Another caveat: lots of internal feedback will be bad ideas. This is OK. I’ve found it helpful to start with praise and then ease into honest and clear feedback that sets realistic expectations about the likely priority of the suggestion. For example: “You’re definitely right that adding mouse-wheel support would make it easier for power users. I’ll add that idea to the ranking question in our next quarterly user survey. That said, only about 20% of power users log in on PCs; the others use iPads or phones only. If the survey doesn’t show big demand for this, I think we’ll probably want to focus on features that don’t need a mouse.”

• Persuasion is better than force. Don’t yell at your team. Ever. Also, you should almost never force your team to do something that they strongly don’t want to do. It’s almost always easier to get humans—engineers included—to do what you want if they also want it. That means it’s your job to persuade and convince, not to “pull rank” as a senior person. Even if you have decades of experience and they’re just out of college, it’s still smart for you to spend the time to make a convincing, evidence-based case for your opinions, and to respectfully engage with theirs. You’ll win more respect that way, and you might end up avoiding a mistake if they’re right!

• Like and respect engineers. This one is intentionally vague, but the basic idea is to ensure that your team knows that you like them and respect their work and their time. Get to know team members as people, not just “resources”. Hang out with the team, especially when you don’t need anything from them. Do favors for the team, like bringing coffee in the morning or dinner if they’re working late. Give away your conference swag. You get the idea: find ways to show that you care. Some PMs (often those infected with a “CEO of the Product” mentality) treat engineers imperiously as if the PM job is more important or more prestigious than the people who actually build the product. The best PMs are humble and helpful—they serve their teams rather than the other way around.

Most of the techniques above are common sense: if do your job effectively while treating your team well, then they’ll like working with you!

This post is a lightly-edited version of an answer I posted on Quora several years ago.

TL;DR - When hiring PMs, you sometimes must choose between candidates with more relevant subject-matter expertise vs. candidates with better generalized SaaS PM skills. Generalists usually work out better, because it’s usually easier for a great PM to learn a new industry than for an industry expert to become a great PM.

In my experience, a product management candidate’s existing subject matter expertise is much less important than their ability to quickly gain subject matter expertise.

Obviously you want both: a PM with both great generalist skills and excellent subject matter expertise. But when forced to compromise on one or the other, I lean towards experienced PMs without same-industry experience over industry experts without strong PM skills.

After 15+ years managing PMs, hiring PMs, and working with PMs at both BigCos and startups, I’ve repeatedly seen great PMs come up to speed on a new customer segment, technology, and competitive landscape within a few months. It's a joy to watch how fast this learning process can be for PMs who are good at quickly getting inside the heads of new customers and quickly understanding what it takes to satisfy those customers' needs.

The reverse—subject matter experts without PM (or PM-like) experience who can quickly become great PMs in a small SaaS startup—seems to be fairly rare. I've also seen cases where industry experience can be as much of a hindrance as an advantage. PMs who are too familiar with "how things have always been done" might be bringing too much baggage and not enough critical distance and open-mindedness to the table.

I'm not implying that industry experience is irrelevant, only that it tends to be easier and faster for a great PM to learn a new industry than for an industry expert to become a great PM.

When recruiting, I think that the sweet spot is PMs who have solved similar problems for similar customers in an unrelated industry and whose background and personality suggests empathy for our customers. I call this “PM/Customer Fit”. For example, when hiring a PM for a veterinary practice software startup, healthcare PM experience would be preferred but optional, but “liking pets” would probably be required. Another example: most of the customers of my last company Cantaloupe were multi-generational family-run businesses who employed mostly blue-collar workers. PMs who had an affinity for family businesses and blue-collar work would have a leg up.

Of course, not all PM experience is transferrable across products and industries. For example, consumer vs. B2B products also tend to require somewhat different PM skills. But what makes Consumer<=>B2B transitions challenging isn’t the PM’s lack of industry knowledge. Instead, the habits and expectations learned as a Consumer PM might lead PMs astray in a B2B business, and vice versa. It’s usually these kinds of higher-level patterns and habits—not facts or connections in a particular industry—that determine PM success.

Caveat: I’m not saying that you should *never* require industry experience. For example, if you’re building a highly-technical product and the PM is expected to deeply understand the technical design (e.g. a database or API product) then it’d be really challenging for PMs to be successful without strong technical skills and some experience targeting developers as customers. But my general point with this post is that those “industry experience required” cases are both rarer and less specific than you might think.

This post is an edited version of an answer I wrote on Quora several years ago.

Years ago when I first started doing Product work, I knew Sales, Marketing, and Support existed, but I viewed them as supporting players whose main goal was to get the product into customers’ hands and unblock them if they got stuck. My naive mental model of the customer relationship looked like this:

As I learned more about how B2B companies really worked, I realized that only inexperienced product managers took this myopic view. A great example was my first week at Splunk when I tried to install and use the product. Setup was confusing, documentation was limited, and some use cases required a lot of trial and error. How could a successful company’s product be so hard to get working?

So I asked a Splunk customer about this. “Sure, some things were hard at first”, he said, “but whenever I get stuck I just call tech support and they know how to fix it.” To me, requiring a support engineer’s help was a product failure. But to the customer, it was a minor annoyance. As long as he got unblocked, which part of the company did the unblocking didn’t matter.

Here’s another example from a few years later: at my first board meeting as VP Product at Cantaloupe, I presented two Product slides in a long deck that otherwise focused on financials and sales. I was excited to brief the board and expected many questions, but everyone just nodded and within a few minutes the meeting was back to cashflow, budgets, and churn risks. Like that Splunk customer above, the Cantaloupe board didn’t see the product as the sole focus of the company; instead, the *company* was the focus. The product was just one piece. An important piece, sure. But just one piece.

After that, I started noticing the breadth of customer interactions outside the product:

• Our billing process was complicated and partly manual, which caused mistakes in customers’ monthly bills, which in turn created headaches and churn risk for the sales team.

• Customers who interacted with Support on a regular basis were more satisfied than customers who tried to muddle through on their own.

• Customer Success Managers kept finding smart workarounds for customers which helped us avoid building low-priority features into the product.

• Salespeople would ask if they could use the promise of a particular new feature (which we were building anyway!) to help close a renewal deal.

I finally got it: in SaaS, the important “S” is the “Service”. The Software is just a means to an end. To deliver a service, a product is needed, but that’s not enough. The product needs to be sold and renewed, new customers need to be found and educated, technical questions need to be answered, the customer’s money must be collected (accurately!), and so on. Unless all those pieces work seamlessly together, customers won’t be happy and the service won’t succeed.

Here’s how I think about customer relationships today:

One can quibble about the size of each slice, but the fundamental idea is that the product is part of a service that contains multiple, inter-dependent parts. The product is a feature of the service.

Note that by “product” in the pie chart above, I don’t mean “Product Managers”. I mean, literally, the thing that customers interact with that was the result of hard work from engineers, designers, data scientists, PMs, and everyone else who contributed. My point is that in addition to a product, customers *also* interact with Support, Sales, Finance, Marketing, etc.—and all those parts can (and should!) work together to deliver a great customer experience.

OK, now I get it too. So what?

Thinking of the product as just one slice of the “Service Pie” seems like a minor thing, but it made it much easier to spot cases where the Product team could help the rest of the company deliver a better service. This led to many low-hanging-fruit wins. For example:

• We built an “Internal Tools Backlog” and allocated a small percentage of total engineering capacity to proactively whittle away at the biggest pain points for the Finance and Support teams.

• We met quarterly with the Support team to understand the top support issues, which we triaged together to decide which ones should be fixed soon.

• The PM team started attending monthly Account Review meetings run by the Sales team, so that we could hear about deal-blocking issues earlier and help advise them how to work around customer concerns.

• At the Sales team’s request, we scheduled work to improve the “demo site”, which made it easier for non-technical salespeople to deliver professional demos to prospects using more realistic data.

• We started collaborating with Marketing to help them proactively plan PR around our every-3-weeks product releases, and to align product documentation with marketing messaging.

• We started putting more effort into documentation for each new feature.

• We got more methodical about sharing product updates with the company, so that salespeople and CSMs could train themselves ahead of time before we released new features. (Better documentation helped a lot here!)

• I helped the Marketing team redesign the corporate website to better align with our mobile-centric product strategy.

• A PM sat with the Finance team while they generated monthly bills. He was able to identify fixes—both in our billing systems and in Finance’s manual steps for customers with unusual deals—that helped reduce billing mistakes.

• We hammered out unambiguous guidelines for how salespeople should (and should not!) talk about unreleased product features.

In other words, by thinking of ourselves as team players we started *acting* more like team players. The result: better customer experience, faster revenue growth, and much better relationships with our peers inside the company.

But wait, we’re already too busy!

You may worry that helping other parts of the company would distract PMs from improving the product, or would tie up too much engineering time. I was worried about this too. But in practice, having a company-wide focus changed less than 10% of what PMs spent their time on. For engineers it was more like 5%. And that 5%-10% paid for itself in faster sales and better cross-team efficiency. Plus it made work a lot more pleasant for everyone: less complaining, more collaborating.

Does this approach work in a big company?

No, at least not in my experience building B2B and developer products at Microsoft. In a small company, every team has the same scope. For example, Sales sells the same product that Product and Engineering design and build. In a big company, salespeople, finance, and (sometimes) marketing and support deal with multiple products. So it’s unlikely that any particular product’s PMs can make company-wide improvements to the overall customer relationship.

Many big companies have a centralized Product team, which in theory helps solving company-wide problems, and all BigCos obviously have PM and Engineering teams that maintain internal tools. But the most ambitious and skilled PMs, engineers, and executives seldom focus on internal-facing projects. This means that internal-facing teams are usually starved of resources and talent.

Also, human psychology is optimized for individuals and small groups. If your company has 1000 salespeople, they’re “out of sight, out of mind” for PMs and engineers. Psychologists even have a name for this: the identifiable victim effect. If a company has 10 salespeople, 5 marketers, 5 support engineers, and 2 accountants, you’ll probably see them every week and it’s human nature to want to help them.

This is a blog about doing product management in a small B2B SaaS startup.

Most PMs work at large companies. As a result, both supply and demand for SaaS PM-related content skews towards advice that may not work as well in smaller companies. It’s also easy to find “founder stories” about how they landed their first customers and achieved product/market fit. But there’s a dearth of info for PMs about how to navigate the time in between: the Series A-to-C period when a startup has 20-400 employees, $0.5M-$50M ARR, and 1-10 Product people.

But there’s a lot for PMs to do during that time! For example:

• Crossing the chasm from early adopters to mainstream customers

• Growing a single product into a portfolio of products for different segments

• Improving prioritization and roadmapping, and building a “just right” process for both that enables predictability without slowing everyone down

• Keeping the company in sync, despite massive headcount growth and brand-new teams like Customer Success, Support, and Finance coming on board

• Fighting serious competition, often for the first time in the company’s history

• Supporting the transition from “founder sales” to repeatable Sales & Marketing

• Efficiently collaborating with many newly-hired engineers who won’t have the business context nor interpersonal history of the OG engineers

I’ve spent the last 10 years figuring out solutions to these “Series A-C” PM problems, and I’d like to share some practices that have worked well, as well as some fails.

Why Am I Writing?

“When you read, try to understand the writer’s goals. No one ‘just writes’.
Everyone has an angle.”

— my 10th grade English teacher

Here’s my angle: I’m starting to look for a new job leading the Product function for a “Series A-ish” B2B SaaS startup, either as the first Product hire or inheriting a team from a founder who’s been leading Product as a side gig. I’ve done exactly this before at Cantaloupe and loved it, and now I’d like to do it again!

But Head of Product is a scary hire for a small company, because most startup founders and early employees have never worked with a PM who’s good at “SmallCo” product management. There’s a few reasons for this:

• Many founders and early employees started their careers in big companies, so they’ve only seen BigCo PMs in action.

• PMs don’t exist in university CS programs.

• Some startup denizens have only worked at tiny companies (<10 employees), which usually don’t have nor need full-time PMs.

• Many PMs are not very good, perhaps for the same reasons that product management tends to vary a lot between companies.

As a result, many startup founders and employees have a fuzzy idea of what what successful SmallCo product management looks like. This blog is an attempt to clear up this fuzziness with examples, tips, and tricks from my and others’ experience of doing Product in small B2B companies.

In addition to de-risking the Head of Product hire (which might be me!), writing a blog is a good forcing function to clarify my own thinking about PM.

I’m also hoping to get feedback from other PMs and PM-curious folks, and to learn from readers’ experience while you’re learning from mine. So I’ll leave comments open for further discussion. Just stay polite, OK?

About me

I’ve been doing Product for a while. Here’s some details:

• I’m currently Head of Product @ AON3D, building a 0=>1 SaaS business for a YC-backed manufacturer of large-format, high-temperature 3D printers. I’m leading PM and Design as well as occasionally pinch-hitting as a software engineer and software engineering manager.

• Head of Product @ UpCodes, a YC-backed building-code compliance solution for architects, contractors, structural engineers, and others in the construction industry. I led Product, Design, and Content teams to grow our paid signups 3.6x within 10 months, which came after a previous period of stagnant growth before I joined.

• VP Product @ Cantaloupe Systems, the largest SaaS provider for the vending industry. I led PM from from $2M->$16M ARR, and from a single early-adopter product to a portfolio of products for mainstream customers. After a $85M, 4x-to-investors acquisition in 2017, I led PM for the acquirer (recently renamed Cantaloupe, Inc.) for a year before leaving to work on my own startup ideas and side projects which I may discuss in later posts. (Spoiler: COVID killed my startup!)

• Senior PM @ Splunk. I was PM #4 and was responsible for Splunkbase (Splunk’s app marketplace) and product-to-web integration in general. I also led the cross-functional team that built Splunk's Application Management solution V1.0, which focused on analytics, operational reporting, and troubleshooting for Java Application Servers.

• Principal PM @ Microsoft (MSDN & TechNet) - I was PM of msdn.com and technet.com, which at the time were the Web's largest community sites for developers and IT-Pros. I was responsible for terabyte-scale analytics, integrating MSDN with Visual Studio, and trying to fix navigation and site search across millions of pages.

• Group PM @ Microsoft (Server Management Products) - I co-founded the team that built Microsoft's first Application Management product, leading a team that grew to 20 PMs responsible for Microsoft's server-operations-management products including Operations Manager (now called SCOM).

• Various Developer Roles. Before moving to PM, I worked as a software developer at various startups during high school, college, and for a few years after. Here’s some highlights:

  • I was employee #7 at Stockpoint, a financial information startup. I led the web development team, managed site operations, and scaled out Stockpoint's SaaS offering.

  • A part-time college job turned into me being employee #3 at the company that became ask.com.