Be Like In-N-Out

More businesses need to be like Chick-fil-A and In-n-Out. The menu is simple, the service is excellent, and the quality is high. Customers don’t have to learn a new menu each month, smile at apathetic employees, or brood over an incorrectly filled order. For those reasons, customers love them. 

 The lesson is clear: do less, do it well, and be consistent.  

How else do you explain their durability? Both In-n-Out and Chick-fil-A were started in the 1940s, but growth hasn’t plateaued nor has their cult-like following. Chick-fil-A’s revenue tripled between 2010 and 2019. Meanwhile, the rest of the fast-food industry has attempted to compete in the market by serving up one ludicrous menu item after another. Carl’s Junior created fruit loop donuts. Taco Bell sold us Kit Kat quesadillas. It’s like the fast-food industry conducts strategic planning using junk food mad libs. And McDonald’s? They tried to make us eat salad! 

As a product leader, you should strive to be like In-n-Out. If your customer cherishes you for beef, keep the beef coming. Don’t confuse them with lettuce topped with a paltry dose of carrot sticks and cucumbers. Resist the pressure to become something you’re not.

It’s unfortunate that most software companies, and the product leaders within them, don’t subscribe to the same ethos as these fast food icons. Successful software businesses begin as simple applications that succeed by delivering 10x greater value — relative to the alternatives on the market — with a limited set of features. Chrome won the browser wars because it is more secure, faster, and simpler than all other browsers on the market. Amazon became Amazon due to a multi-decade maniacal focus on selection, price, and convenience.

Being the best at a few things is a defensible strategy for building multi-billion dollar companies.

Myspace lost to Facebook because Facebook kept it simple. While Myspace layered on features, the product became slower, more difficult to use, and the primary value to the user — adding friends, sending them messages, and posting photos — was buried in an insidious medley known as “feature creep”.

Meanwhile, Facebook pulled off an opposing plan. New feature development was halted on several product lines and the bulk of the company turned its attention to a few initiatives — making the website fast and accessible from anywhere on the planet, ensuring users could easily find and add friends, and simplifying the user interface so that uploading photos and messaging others was trivial. 

Within 18 months, Myspace went from the dominant social network on the planet to a dying business and Facebook went on to become a once in a generation company worth several hundred billion dollars. The flip flop was shocking and I was there to witness it. 

Facebook’s focus on a few things that matter is what propelled it to the dominant social platform on the planet. However, their lack of focus in recent years has, ironically, turned it into a replica of a declining Myspace circa 2010. Users can donate to charity, find romantic partners, sell old furniture, play games, live stream video, send money, and find a job. But what happened to keep in touch with my closest friends and family? That was lost along the way. 

Your challenge as a product leader is to create more value for the customer without introducing the clutter that obfuscates what you stand for. 

What three things does your customer love you for? Is it speed, simplicity, and security? Convenience, low cost, and selection? Assuming you have this understanding, what plans do you have to enrich those values? And, most importantly, are you prepared to resist or kill the products that break your customer’s expectations of you? No, McDonald’s, I don’t want a salad. 

Just because you can serve your customer a salad doesn’t mean you should. Apparently, Burger King has decided that the way to survive in the hamburger market is to serve something that isn’t even a real hamburger. What clearer sign do you need that a company has lost its way? By rolling out a meatless patty they are willing to concede the market to any competitor willing to stick to what most people want, which is a good-tasting meat patty. 

Don’t be like Burger King. Don’t be like McDonald’s. Be like In-n-Out. Keep your product simple and its features aligned with the value your customers have come to know you for. Be fun. Be simple. Be consistent. Be convenient. Be low-cost. Be accessible. Be easy. Be a few of those things, but don’t try to be all of them. And no matter what, don’t be like Cheesecake Factory

Why Standups are Useless and How to Run Great Product Team Meetings

The majority of meetings are a waste of time. And in my opinion, one flavor of meeting that tops the charts in uselessness is the “status update” meeting. You know this meeting— the meeting where everyone gets together to share what they’ve been doing. It’s ironic that meetings like this exist because it gets in the way of people actually doing something productive. A cross-functional group of people (product, design, engineering, marketing and so on) working on a new product doesn’t greatly benefit from status updates.


“Standups” Won’t Save You

I don’t claim to know the perfect recipe for a cross-functional product team meeting, yet I can say with a stiffened spine that the worst breed of status update meeting is the “stand up”, which has been popularized in agile methodology. I’m not the first to say this as others have had similar observations and provided comical opinions

Most standups occur daily and some teams reduce the frequency to a few times a week. The majority of standups are short, yet often meander into casual conversation where people talk about things unrelated to work, like what they did over the weekend. None of this helps you build quality products at a fast pace. We’ve become so enamored with standups that popular tools like Slack even have a standup feature built into them.

But my stance on standups is the polar opposite of the trend. The only time in which a standup is truly beneficial is in the run up to a product launch. That’s when your troops are about to storm the beach and you want to make sure they are prepared. Are we ready to flip the switch on the A/B test? Is marketing ready to publish the blog post and push out the PR pieces? Does customer service have the scripts they need to answer customer questions that will come in right after launch? Do a standup when nearing launch to make sure the troops are ready to sack Normandy. That’s when it’s useful.

In any case prior to a launch, standups are mostly a waste of time. That’s because the bulk of the product development process centers around (1) building (2) making decisions. Point #1 is obvious (of course the team is busy creating stuff), but point #2 deserves a discussion, since that’s the meat and potatoes of the subject. 

Making Decisions

Hundreds of decisions need to be made during the development of a new product, like:

  • What’s making the cut for the MVP?
  • Who is the lead designer going to be?
  • How will we promote/merchandise this new feature?
  • Will we be A/B testing it? 
  • What are our goals and key metrics?

Those are the obvious big decisions that nearly every product team needs to make. But there are also a long list of mid-sized and bite-sized decisions that need to be made along the way  like:

  • Do we need to create a new UI component or can we use the one from our existing component library?
  • Is feature ‘X’ worth building since it balloons backend scope by 3 weeks?
  • Will this be a 50/50 A/B test or should we do a simple holdout group of 95/5?
  • Are we shipping on all three platforms in parallel across web, iOS, and Android?
  • Can we cut scope on Android since it’s only 5% of our users?

For anyone that’s built a product of reasonable scope/size, we all know that the set of decisions to make balloons as the project kicks off. It’s only then that you start to peel back the onion and realize the complexity of the task at hand, in addition to the set of decisions that must be made in order to unblock the project and keep it moving. 

The universe of decisions to make begins quite large. As the product team progresses through those decisions, the hard (i.e. big) decisions tend to be made earlier in the project (e.g. “What’s making it into the MVP?”) and the mid-sized and smaller decisions tend to come in later in the game (e.g. “Can we simplify UI component ‘X’ to reduce the backend scope by a few days?”). The total number of decisions to make also approaches zero as a team gets closer to launch. 

(Lots of big decisions to make early on with fewer and smaller decisions to make later)

But let’s recall the point I made a few seconds ago— the team is unblocked when decisions are made. “Unblock” is the magic word here.

Unanswered questions act as headwinds or speed bumps when building products. Using the classic example of MVP cutoff, a team must decide on which features will be included or excluded from an MVP. That’s a hard decision to make so product teams typically move slowly through this phase of development. This is one of the driving forces behind the creation of the Google Design Sprint methodology. As the methodology explains, you can use their design sprint method to “shortcut the endless debate cycle” to arrive at a few key decisions regarding what the first product prototype will be. Each unmade decision (i.e. each unanswered question) pumps the brakes on the development process as a whole. Protracted decision-making leads to protracted product development cycles, often by weeks or months (indicated by the red bars below). The Google Design Sprint method is one great example of how a team can make important decisions more quickly, which ushers them through the process of arriving at their first testable prototype.

(Answered questions lead to delays in development indicated by the red bars)

More on Standups

Before I share with you the meeting format that I’ve learned is most effective for product teams, I’ll harp a bit more on the ubiquitously popular “standup” meeting. 

Let’s take a closer look at the prescribed format of a stand per agile methodology. Members of a standup (i.e. everyone on the team) are asked to share the following:

  1. What did I work on yesterday?
  2. What am I working on today?
  3. What issues are blocking me?

There are several big issues with this format. 

First, why should I care about what everyone worked on yesterday? Most of the time, you don’t care, and you shouldn’t care what others work on day-to-day. The practical reality is that you only care about what another team member worked on yesterday if it enables you to do your job (i.e. it unblocks you). Anything shared that does not explicitly unblock you is meaningless noise.

For example, a product manager may share something like, “Yesterday, I did one interview, worked on some specs, and interviewed one customer. Today, I need to interview one more design candidate and then I’ll update some of the user stories in the spec based on the questions I received from design. I’m not currently blocked on anything.” This example of a typical standup update is useless in terms of what it does to enable a product team to build a higher quality product at a faster pace. 

Similarly, why should anyone care about what I’m working on today? Again, it only matters if what one person is doing today unblocks another person on the team. But if it’s really that important of a blocker, should that person wait until the following daily standup to make that known? Why not email that person or swing by their desk as soon as you’re running up against the roadblock and seek to remediate the issue as it arises? 

Now, let’s dissect the third bullet point, which is to share what you’re blocked on. A team member may be blocked on something in one of two use cases. The first is that the task they are blocked on simply takes a lot of time. An example would be backend engineering waiting for more clarity on frontend specs before they can finalize the engineering design docs for what they must implement. The second reason why someone may be blocked is that a decision hasn’t yet been made. It’s less useful to say “I’m blocked by X” than it is to say “Hey, why don’t we get together and make a decision on X, so that we can move forward?”

Standups don’t carve out time for decision-making, which is the ultimate blocker. Rather, standups are designed to simply make the blocker known, yet not resolve the blocker. Resolution matters more than awareness.

A Simple Agenda to Keep Things Moving

I’d like to propose a simpler alternative that leads to more productive product meetings and improved product development cycles. It’s something I learned through trial and error in my career. I’ve found it to be the simplest, most effective meeting format for any product team (and for most meetings in general). Here it is:

  1. Action items: who is handling what key action item and by what date?
  2. What decisions need to be made?

I would run this meeting one or two times a week depending on the volume of decisions to be made. Sometimes as much as three times a week. Early in the development of a product, when a team needs to make many decisions, I increase the frequency of these meetings. As development progresses, the volume of decisions to make decreases and the proportion of time spent on building increases. Similarly, the magnitude of the decision (i.e. how hard or important it is) tends to decrease as development progresses.

If the team is effective at surfacing key decisions and in driving towards decisions expeditiously, then you can cut out weeks or months of unnecessary delays in the product development lifecycle. So, how do you make sure this is done?

Collecting Open Questions

To prepare for running effective product team meetings (i.e. decision-making meetings), I would go to each function lead on the product team (design, engineering, marketing, etc.) and ask them what decisions they needed made. I would collect the open questions and pull them into the agenda. It’s a simple enough task so you can ask people as you swing by their desk, ping them over email or Slack. In parallel, I would maintain a set of action items that came up during the decision-making meetings. From the set of open questions and action items I would compose an agenda and it would look like the following:

Action Items

  1. (Josh) Share latest iOS designs with Tammy by 9/13
  2. (Deanna) Send marketing language for review to compliance by 9/15
  3. (Andy) Sync with data science on how to configure the A/B test buckets by 9/15
  4. Etc.

Decisions to Make

  1. Should we include the 3-5 days worth of UI design polish as part of the MVP launch or not?
  2. Should we ask executive staff for support to get one more backend engineer or is there no parallel processing that can be done with extra resources to bring in the launch date?
  3. Who is going to take the lead on starting customer development for the next milestone on our roadmap? Should we even start that yet or punt it by a week or two?
  4. Etc.

If I were leading the meeting, I would run through the set of action items to make sure we continue to execute on the critical tasks each of us signed up for and hold ourselves accountable to hitting our deadlines. Any new action items that came up during that portion of the discussion would then be added to the list in realtime. We would normally move through the action items portion of the agenda in less than 10 minutes. 

The remainder of the meeting (which we normally reserved 60 minutes for) would then be spent on making decisions as a group. In many cases, a side conversation had already happened by a few relevant members of the team (e.g. design chatting with engineering about a particular aspect of the designs) and they could walk the team through the context of the open question and their recommended answer. In those cases, decisions were typically made in a matter of seconds or a few minutes. In minority cases (I would estimate about 30% of the time), the decision required ample discussion and might be too complex for a group setting and/or the time allotted. 

In those cases, I would ask 2-3 of the most capable and relevant members of the team to form a quick working group either later that day or the following day to discuss the item and come up with a recommended decision. Their recommendation was then shared with the rest of the product team either over email, Slack, or in person at the next product team meeting. We effectively had multiple concurrent decision-making meetings going on in parallel, constantly driving towards reducing uncertainty and maintaining momentum. 

(Use team meetings and small breakout discussions to quickly eliminate unanswered questions)

The more we had these meetings, the more effective we became at making decisions as a team, or in forming the breakout group to drive towards a decision and then close the loop with the rest of the team. 

Decision Log

Something else to consider adopting is a decision log as part of this meeting format. I suggest using a single Google doc for maintaining a full record of all prior meeting agendas, as well as prior decisions made. That comes in handy when a post-mortem is run after the product has been launched to assess what the team did well or could have improved upon. Often, the full context of prior decisions made is lost, especially if those decisions are made in isolation by a few people and/or made several weeks or months in the past. 

Maintaining a record of all prior decisions makes it very easy to reflect on the project during a blameless post mortem and the ability to identify the root cause of issues that eventually come up. Or, better yet, the log of all prior decisions made may help the team identify root cause behind a failed product launch. To make things convenient, I’ve created a copy of the agenda format and decision log that I used to use with my product teams. It’s publicly available for you to copy and use yourself. It’s simple enough but thought I’d share nonetheless.

Wrap Up

The format for standups popularized in Agile methodology, unfortunately, isn’t well calibrated for driving efficient product development within a team. The root cause for long development cycles is that decisions weren’t made quickly and frequently. By replacing daily standups with less frequent decision-making meetings, product teams can save themselves lots of wasted time and build products much more quickly.

What Makes for a Good Product Manager?

Over the course of my career, I’ve worked on product at Facebook, Twitter, Quora, and Wealthfront, and have advised dozens of other companies on the role of growth and product. Now, as an investor at Unusual Ventures, I get exposure to an even broader collection of companies, and the product cultures within them. Despite that exposure, there is a lot about the role of product that I still don’t understand. But what I can say for sure is that there are as many philosophies on the role of a product manager (PM) as there are letters in the alphabet. And we’re nowhere near getting to a point of agreement on the basic question of, “What makes for a great product manager?”

The confusion surrounding expectations has always stood out to me as one of the most unique and challenging aspects about this role. If you ask an engineer what they want from a product manager, they’ll give you an answer from their perspective. Some might say, “I want them to do all the stuff I don’t want to do, like take meeting notes.” Others might say, “I want them to be proficient with SQL, so that they can pull data.” Or, “I want somebody with good design sense.” Then, if you ask a designer what they want in a PM, you’ll probably get a different set of answers. Same thing when asking marketing or an executive of the company. If you ask the PM themselves (or Twitter for that matter) what they think a PM’s job is, you’ll get yet another set of perspectives.

These completely different expectations make the PM job very difficult relative to most other positions because what makes for a great PM can’t be narrowed down to one or two objective measures. PMs have a broader set of definitions and expectations to live up to. If you view each of these expectations as a set of circles, the world’s greatest PMs are those who are very good at a combination of these overlapping expectations. For example, you may have a PM who’s really great at writing SQL queries, which might earn them the respect of an engineer. But they also need to be excellent at conducting customer interviews and reflecting the voice of the customer to really impress designers. Ideally, you’d find somebody with an overlap of these skills. A baseline set of expectations for a junior to mid level product manager might look like this:

To make things even more complicated, these expectations can also vary from company to company. Some companies don’t even want to have product managers. That’s how conflicted the industry feels about the product management role. However, at the risk of being too prescriptive, I’ve laid out my framework for PM skills development below.

Foundational Skills

In my opinion, below are the most basic set of skills that a Product Manager should master in order to establish their role within a team:

  • Create Requirements — They can create clear product requirements that satisfy the preferences of the engineers and designers they work with (i.e. it unblocks design and engineering). There are many different approaches to product requirements, so there shouldn’t be a religion around a particular style. What matters most is that design and engineering feel enabled by the requirements a PM produces.
  • Customer Feedback — They can bring together basic customer insights through customer interviews, reading customer service tickets, etc. They do an adequate job of reflecting the baseline expectations of the customer they’re building the product for based on an explicit set of requests from the customer (e.g. the customer says a part of the product is broken).
  • Data Insights — They have some basic data proficiency where they can look at the data related to their product and potentially use that data to make decisions. They will have working knowledge of data languages like SQL and know how to use popular business intelligence tools like Looker, Google Analytics, and so on.
  • Run Meetings — They can run effective meetings with the team. That includes setting the agenda and tracking action items. For foundational abilities, this does not include driving decisions within the context of product meetings as driving decisions is more common amongst senior product leaders. I’ll touch on this more in a moment.

From what I’ve seen, having this baseline set of skills means you can be average-to-good and generally command some reasonable amount of respect from cross-functional peers in engineering and design. Then there are the additional skills that separate a beginner PM with foundational skills from a more experienced PM with intermediate capabilities.

Intermediate PM

To be an intermediate PM, you also need to layer on the following skills on top of the prior set:

  • Customer insights. Beyond collecting the plainly stated forms of customer feedback, this means deeply understanding the problems/needs of a customer and how that customer has historically solved those problems or met their needs. This PM can then diagnose how the product he/she is building will solve the customer’s unmet needs.
  • Basic design knowledge. Good PMs have working design knowledge so that they can distinguish between bad, mediocre, and good design. This predominantly comes down to UX fundamentals and not advanced topics like color theory. Does it require too many taps/clicks? Is the product copy unclear? Does it meet the stipulated customer needs? Is the cognitive load too high? Is the information hierarchy correct? These are the sorts of questions that a good product manager will ask when working through prototypes.

Exceptional PM

To be an exceptional PM, you must combine the previously mentioned skills with a few more skills. This person can operate at the executive level or be the product lead on the biggest, most important product initiatives within a company.

  • Customer Innovation. This PM not only knows the explicit customer requests and has intimate knowledge of the customer’s needs, but can introduce new products or features that exceeds the customer’s expectations and innovates on the customer’s behalf.
  • Vision and Strategy. Exceptional PMs can also internalize founder-level vision for the company and turn that vision into an actionable strategy. They have the most keen line of sight into the series of products/features that need to be built to achieve the founder’s vision. And once they have the vision and strategy clearly understood and explained to their team, they can enforce great execution against the vision and strategy.
  • Broker hard decisions. The best product managers are those that can also drive a team toward making a high quality decision in a world of uncertainty. Foundational and intermediate PMs can arrange and run the meeting, but aren’t necessarily great at driving a product team towards a decision in difficult situations. The best PMs are those that everyone else in the room looks to when making a hard decision and they typically make the best tradeoff decisions given the circumstances.

As you can see, the requirements for becoming an exceptional product manager are high and numerous. Going back to the original venn diagram analogy, exceptional product managers need to have a lot of overlapping skills and each function within the company places particular emphasis on some of those skills. Engineers might assess a PM based on data proficiency and quality of requirements, design might assess based on customer-centricity and some degree of design thinking, while executives may assess a PM based on the ability to lead a product team through complex initiatives and fidelity of vision and strategy. Across the board, everyone is expecting a PM to be a good decision maker.

A needle in a haystack?

That said, it’s no surprise to me that I often hear founders gripe about how they can’t find great product managers. They often say they only come across average PMs. As part of that, I arm them with the above framework so that they can be more specific when it comes to critiquing the caliber of their product managers, in particular once they’ve adjusted their expectations for the level of seniority.

When I dig in more deeply, what they are really saying is that it’s very hard for them to find product managers with the exceptional PM qualities of customer innovation, clarity of vision and strategy, and ability to make hard decisions. Unfortunately for PMs, most founders expect them to have the skillset of an exceptional PM, regardless of their level of experience. This triumvirate of skills (customer innovation, vision and strategy, and ability to make hard decisions) is what I call “Founder’s Feel”.

For example, when Facebook was working on Messenger, it first started out as an integrated messaging app as part of the web client. One day, Mark Zuckerberg declared that it must be made a standalone mobile app and that Facebook users would be required to download it if they wanted to chat directly with one another. That wasn’t an obvious decision at the time, certainly to most of the rank and file employees, yet it was the correct decision given the pressure Facebook was feeling amongst a growing collection of competing messaging apps. Facebook was being unbundled by competing products so they decided to get ahead of it and unbundle themselves. This is the sort of decision-making that great founders make and, sometimes, exceptional product managers can make as well.

I’ll give you another example from my time at Wealthfront. We had just launched our mobile app and the number one source of customer feedback we were getting was that customers wanted to see their daily returns front and center in the mobile app. In other words, customers wanted to be able to log in and see whether their account was up or down relative to the previous day, and they wanted that front and center in the app. I remember telling our product manager at the time that we were never going to do that. The PM looked at me like I was an alien and kept repeating that customers were asking for the feature.

I explained that customers were asking for that feature based on what they thought Wealthfront was at that point in time, which was a tool to manage their investments. But what we were going to be a few years into the future would be their holistic money manager where we would handle their financial planning, banking, investing and so on. Holistic money management is not about showing daily returns because whether the market goes up or down 1% per day does not matter in the long run. Most customers were investing and planning for something several years or even decades down the road. I pointed out earlier that a great product manager understands customer feedback first and foremost. But an exceptional PM knows how to contextualize that customer need within the broader company vision and strategy, and then decide whether or not to implement what the customer is asking for.

Fast forward a couple years, we took daily returns and relegated it to a lower position within the app and put long-term financial planning front and center for the customer. Eventually, we saw that the savings of customers who engaged in that long-term financial planning feature went up by a double digit percentage. Sometimes, listening to explicit requests from the customer can lead you in the wrong direction, as would have been the case here.

Developing “Founder’s Feel”

So what does it take to develop “Founder’s Feel” in order to become an exceptional product manager? How does one go about building strong instincts around customer innovation, a vision for the future, and a knack for making high quality decisions that others don’t necessarily see? The bedrock of it is in knowing the customer better than anyone else.

The way I think of it is that you’re collecting unstructured data every time you have a conversation with a customer. It’s not structured like the data you retrieve from a database. Rather, you’re looking for structure (i.e. patterns) in the data that only becomes apparent once you’ve had enough customer conversations. For example, imagine that an insight from a customer conversation is a data point that you plotted on some nebulous graph, like I’ve shown below. Each time you have a conversation you collect insights and start plotting them into groups based on similarities/themes. Once you’ve had enough conversations, the themes start to cluster around common insights or customer needs.

Once you hone in on the clusters they start to make sense to you and “feel” obvious, especially after you’ve had enough conversations with a customer. In the below example, each cluster outlined in red could lead to a meaningful product decision.

Each time you talk to a customer, you capture unstructured data. If you have enough conversations with customers, that unstructured data starts to take shape in the form of extremely strong instincts around potential for customer innovation and product vision that seems less intuitive to others. That’s what “Founder’s Feel” is.

The founders of Wealthfront talked to hundreds of initial customers face-to-face and read most customer service tickets from the first couple thousand customers. Several years after founding the company, the founders continue to read customer service tickets and talk to customers face-to-face. When you compare their ability to make a decision in an uncertain environment vs. a product manager who hasn’t talked to any customers, there’s no comparison to be made. They have a “feel” for what to build (and not build) for Wealthfront customers that is unmatched due in large part to the sheer volume of unstructured information they have collected over many years while building the company.

Closing Thoughts

Returning to the original question: What makes for a good PM? The answer is it’s really complicated.

To start with, good PMs can navigate ambiguous expectations and can apply their skills based on the team’s needs. They know the different levers to pull depending on who they’re working with and can adapt accordingly. One thing that can’t be sacrificed is knowing what the customer needs better than anyone else. This means doing customer research, design testing, and diving into customer support tickets, spending time sitting with the customer support team, and so on.

If you’re just getting started as a PM, focus on building the foundational skills I outlined above. That’ll be the foundation through which your cross-functional peers see the value you add. With time and practice, you can hone the additional skill set I’ve outlined that can make you an intermediate or exceptional PM. But if you’re not good at the fundamentals to begin with, you’ll lose the respect and trust of your team and they might wonder, “What is this person’s job exactly?”

For senior PMs, you have to have the ability to broker decisions in situations where it’s hard to make the right call and drive alignment around the vision and strategy. In addition to that, you can weigh in on product decisions using some working design knowledge. I’m not talking about weighing in on square corners versus rounded corners. I’m talking about the overall flow of products, if the experience is clear or cumbersome, and if it meets or exceeds customer’s needs or expectations.

Finally, the rarest of PMs develop their own “Founder’s Feel” — i.e. a knack for making the best strategic decision that’s informed by a top rate understanding of the business, customer, and the market. They know how to work under uncertain conditions and get a sense of the bigger picture. Those exceptional PMs can translate the founder or CEO’s vision into a clear execution plan.

With all this in mind, though, my default position is that the vast majority of product teams are better off being led by a small group of cross-functional owners as opposed to the outdated notion of “the PM as the CEO of the product”. The most effective product teams are those where the leads on Product, Design, and Engineering (and sometimes other functions like marketing, customer service, and data science) are all mutually bought in to being experts at understanding the vision, the customer, and have shared ownership of the outcome. This means that a Product Manager should often defer to Engineering or Design when key decisions need to be made, specifically when those other functions are better fit to make those decisions. And that’s often the case! I would argue that a great PM also shows “Founder’s Feel” by referring to the right person in the room to make the decision.

In my experience, small group decision making typically leads to vastly better outcomes and if you have a true product leader, that person emerges naturally just like any leader does. There’s no explicit conversation about “who is in charge” of the group. Rather, they do such a good job that the peers around them see it, they know it, and there’s not a discussion about it. That person simply rises to the occasion. It’s the person that everyone in the room naturally turns to for the hard decisions and the mark of an exceptional PM.