But the right processes, implemented at the right time, are critical to maintaining velocity and sanity as you scale. Asking yourself two simple questions can help you implement the minimal amount of process to keep you nimble and organized.

Question 1: What's the objective of this process?

When someone suggests a new process, ask: What is the objective? Broadly speaking, processes fall into two categories: Risk mitigation processes prevent mistakes or catch errors before they cause damage, often through additional checks or approvals. Enablement processes remove barriers, eliminate distractions, or provide structure to help the team move faster, often through streamlined coordination or communications.

You shouldn't tolerate repeated mistakes but beware of the impulse to gate everything behind the risk mitigation process. Very few risks are worth a new process, yet in my experience, most processes at larger organizations aim to reduce risk rather than enable velocity.

You should always size and segment risk mitigation processes: Take the time to assess the true cost of the risk you're trying to mitigate. You might be surprised that even seemingly severe events have a relatively low financial impact. In a previous role, we discovered that a risk we were addressing only cost us a few thousand dollars per month. In such cases, you may choose to accept the risk rather than implement a costly, time-consuming process to mitigate it.

Second, segment your process: Effective risk mitigation processes have fast-track options for low-risk situations. While it can be challenging to determine which cases require the full risk mitigation process, it's often easier to identify scenarios that pose minimal risk - define those cases and build fast-track exceptions.

Finally, ensure that every risk mitigation step has bounds. For example, if you add a required approval, set a specific timeline (e.g., 24 hours), after which the request is automatically approved if no action is taken. Risk mitigation processes without well-defined boundaries will grind your velocity to a halt.

Question 2: Is the underlying activity already happening?

If teams are already performing the underlying activity inconsistently or in a disorganized manner, that's usually a strong signal that it's time to formalize the workflow into a repeatable process. But if the underlying activity is not happening today, a process is unlikely to enable the team.

For example, at nearly every scaling B2B company I've been involved with, the sales/eng feedback loop started out as a direct connection - sales reps ping engineers for feature requests and technical questions. This direct communication is great in the early days, but as the company grows, it quickly becomes distracting and chaotic. Implementing a simple intake process, like a form or sheet where reps can log requests for a weekly review, can channel the existing communication into a structured flow.

On the flip side, let's say you want your team to think more strategically. Mandating a "vision process" with required steps for each team is unlikely to spark strategic thinking if it's not already happening. The process rarely creates the underlying behavior; it often adds unnecessary bureaucracy and overhead.

To encourage specific activities, focus on incentives over process. Frustrated analysts will tell you that a lack of dashboards or instrumentation isn't the root cause of product teams neglecting metrics. The real issue is rooted in incentives. While a weekly metrics review can force action & accountability to numbers, it is the direct executive engagement that drives the action, not the meeting itself. The evidence speaks for itself: engaged executives can drive metrics accountability without a formal meeting, whereas a meeting without genuine executive involvement is usually just a ceremonial waste of time.

Processes are a lot like salt. The right amount at the right time makes everything better. But pour on too much too early, and you'll ruin the dish.

Watch out for process creep, where risk mitigation measures get tacked onto an enablement process. Product requirement docs (PRDs) are prone to this trap. The goal of PRDs is noble: get everyone aligned on what’s shipping and why. However, as a central point of product development, PRDs often attract risk mitigation mechanisms.

It might start with a suggestion to run the PRD by localization to ensure international viability. Then, someone suggests a section for customer support to outline training needs. Next, sales want a pre-launch FAQ to help field customer questions. Suddenly, your PRD has ballooned to 27 sections and needs five approvals before a single line of code is written. The once-streamlined process has become a bureaucratic nightmare.

To avoid this, assess each risk mitigation add-on as its own process and apply the sizing and segmentation principles. A well-designed PRD process should have limited approvals, and ample fast-track escape hatches to maintain overall velocity.

If you implement a new process, remember it's not set in stone. Continuously evaluate what's working and what's not. The best processes evolve as you scale.

A complete commitment is a simple concept that is tricky to implement in practice. The complexity and dependencies of the action are often unknown, making it challenging to assign an action to a single person with a specific deadline on the spot, resulting in common failure patterns:

1. Vague outcomes: When it's unclear how much effort is required, a responsible person will often say they will "do their best" or "look into it." This doesn't constitute a complete commitment. Figure out the first actionable step and push for a complete commitment to it. Alternatively, change the commitment to "do x and provide daily/weekly progress updates until delivery."

2. Lack of deadline: If it is impossible to estimate how long an action will take to complete, establish a complete commitment to a timeline. A good template is, "I'll provide a timeline by the end of the day." This gives the responsible person time to assess the action and leaves you with a complete commitment.

3. Shared ownership: Most actions have dependencies, and there is a temptation to make every dependency a co-owner of the outcome. However, as the saying goes, "One person equals 100% ownership; two people equal 40% ownership each." Assigning multiple people to an action dilutes responsibility and increases the likelihood of missed deadlines (and no one is ever fully in control of the outcomes they are held accountable for).

When everyone understands what they're responsible for, when it's due, and that they are on the hook for delivery, they're more likely to take the initiative, work through dependencies, and see it through to completion.

In my experience, many skilled employees with clear and complete public commitments rarely need additional project management structures to deliver. The time invested in setting complete commitments, even under uncertainty, has a much higher ROI than trying to implement reporting and accountability structures after the fact.

This is the 6th installment of the Move Fast series - check out the previous posts:  Great artists steal. Winning product teams copy, Treat your engineers as adults, Set deadlines, even if you have to make them up, Ask for weekly updates, Eliminate unnecessary A/B testing

The challenge is that your market traction will inevitably attract competitors, and if you don't offer a self-serve option, someone else will. Emerging competitors frequently enter through low-end disruption, offering a simpler, lower-cost product targeted to smaller businesses. Defensively opening a self-service channel prevents competitors from gaining a foothold in the lower end of the market.

In all the companies I've been involved with, embracing both sales-led and product-led growth has been essential to reaching our full potential. While having both channels can be a source of complexity and headaches, there are ways to mitigate these challenges and streamline the process. Some common concerns include:

• Channel Conflict: A common concern is that introducing self-service pricing aimed at SMBs might undercut field-sold pricing power or hinder selling larger deals if a small team in a large enterprise can sign up easily through self-service. There are good-enough-to-get-started ways to mitigate these risks. One approach is to limit the seats or deal size available through self-service. You can employ larger discounts in the field channel.

  Your sales ops team can also monitor self-service signups to identify enterprise-level customers and follow up with targeted upselling efforts, or you can spin up a dedicated self-serve to field sales motion team like MongoDB has done with their Product-led Sales team.

• Constrained R&D: Another concern is the potential fragmentation of R&D resources when implementing a self-service channel. There are tools available that can help streamline the process and reduce the burden on your R&D team. For example, platforms like Frigade (full disclosure: I'm an investor) can handle the onboarding flow and other essential components of the self-service experience.

• Product is unsuitable for Self-Serve: I often hear concerns about product complexity, the inability to create a differentiated SKU for single-feature products, or doubts about product-market fit in the lower end of the market. These challenges are rarely unique to self-serve, and addressing them holistically benefits the entire product offering: If the product is too complex to set up without assistance, it likely indicates a broader adoption problem that extends to the field-sold channel. If your product relies on a single feature, it's crucial to expand your offering to remain competitive in both self-serve and field-sold channels. Concerns about the feasibility of self-serve often hinge on assumptions around free trials and virality. While many PLG motions benefit from free trials and virality, these elements are not required in a defensive self-service offering.

If you find that offering a complete self-service option is not feasible for your product, consider providing customers with the ability to get started online. For many potential users, trying out the product is essential to their research process. If you can successfully guide them to a meaningful moment in the product in the self-serve flow that demonstrates value, you'll be well on your way to fending off competitors.

As SaaS companies scale, they amass cohorts of dormant and churned customers. Moving retention becomes one of the most impactful metrics, and it’s tempting to spin up strike teams to address churn or even carve out product teams specifically focused on retention. But unless the retention product team also owns onboarding, chances are slim they will drive sustained outcomes.

Voluntary churn usually correlates with low engagement and seat adoption, and product teams chartered solely with improving retention will focus on reactivating dormant customers. The only tool available is out-of-app messaging - the dormant customers never see app changes - but messaging close to renewals rarely re-engages customers. Customers stand to gain very little benefit from a soon-expiring subscription, and messaging often backfires by reminding them to cancel.

What about involuntary churn? Better retry cycles and dunning can improve churn, but recovery responsibility has to sit with the team that owns payments, or you risk an overzealous payments policy that blocks too many potentially recoverable payments.

Often, the retention strike teams learn that they can’t even message the dormant customers: They might learn that many of the dormant consumers never opted into messaging/notifications or that the customer never connected to the employee directory, leaving the team with few to no options to reach their inactive customers.

Onboarding must establish re-engagement infrastructure - email capture, notification settings, and integrations. These configuration steps can drive small drop-offs in the first sessions but are usually long-term accretive. It’s therefore critical not to split the product responsibility for onboarding and retention infrastructure.

Customer engagement deteriorates quickly - a commonly cited “great” eight-week SaaS engagement retention benchmark is 35% - which means you could reach 100% of customers on day 1 with stellar onboarding or only roughly a third of your customers after 8 weeks with retention or additional configuration efforts.

Ultimately, the most effective retention efforts are focused on day one with stellar onboarding that drives initial engagement and value. Customers realizing value on the first day are more likely to show up on the second day, and so begins a journey of compounding adoption. Keep onboarding and retention efforts tightly integrated, not siloed teams as:

• The best way to ensure customers are engaged on day 365 is to deliver value on day 1

• Onboarding is the highest traffic moment to scaffold long-term retention infrastructure like messaging and integrations

One of the most common reasons startups fail is because there isn’t demand for what they are building. The solution seems obvious - talk to your customers - but it's not as simple as you might think. Collective member and former CPO of Calm, Mads Johnsen, and former product leader turned investor at byFounders, Magnus Hambleton, dive in:

Fall in love with the problem, validate the solution

Early product exploration typically focuses on problem validation: fully understanding customer problems and pain points. However, it is critical that you quickly move from testing problems to testing solutions with your customers. It isn’t sufficient that you solve a problem, or that adopting your solution is a rational economic choice. Many customers aren’t compelled to change behaviors or adopt solutions, and humans don't make perfectly rational purchasing choices: our decisions are colored by emotions, biases, and intangible motivations.

When I built employee benefits products, I would always ask the buyer how they decide which benefits to invest in for their employees. The initial response was typically a logical ROI-focused rationale, ensuring the benefits outweigh the costs. However, when pressed to show such ROI calculations, few buyers can produce them. Instead, the buyers typically end up measuring employee adoption rates or qualitative employee feedback as a proxy for value, says Mads.

To best create products that get adopted and deliver value, you first have to uncover how potential customers feel about your proposed solution. The set of customers you do this with early are often called “Design Partners” and they are a crucial part of setting up your company for iterating toward PMF.

The earlier you test positioning and mocks with potential customers, the better you can adjust your product and maximize your chance of success. Some of the most common reasons founders don’t engage early customers are:

• My product isn’t built yet: You don't need a finished product to test positioning and messaging. Outline the problem you aim to solve and how your solution would be better than alternatives.   Listen closely to objections and concerns to refine your pitch. View pitching and sales conversations not as post-development tasks, but as critical pre-product insights to guide your solution development.

• My product isn’t ready to show: No product ever feels ready to show customers, but even partial visuals elicit helpful insights. In fact, allowing potential users to speculate on unfinished aspects of your product often yields early insight into customer expectations.

• I don’t know how to reach customers: If you can't access customers now, how will you sell to them when the product is built? Build a distribution plan, and use the first version of the distribution plan to reach customers to get early feedback: conferences, online forums, or other channels where your customers congregate are prime testing grounds to validate early prototypes.

• Potential customers don’t respond to my outreach: Lack of interest signals your solution may not adequately address needs and you need to refine your pitch. But if access to users is limited, you can lean on user testing services, where customers are paid for their time to gather feedback. We’ve listed a few user testing services at the bottom of this article.

There is a saying that first-time founders care about product, while second-time founders care about distribution. You need to care about both: success depends not just on how great your product is but also on how effectively you can get it into the hands of your customers. Do yourself a solid and start already on day one.

Maintain a direct line to your customers as you scale

Product organizations can drift away from direct customer interactions as companies scale. It's not that product organizations ignore customers, rather they get feedback indirectly through dashboards, reports, survey results, and support tickets rather than direct interactions.

In B2C companies that are operating with hundreds of thousands of users, it can be very challenging to deeply understand how a single customer interacts with your product and what their underlying motivations are. At this scale, customer insights often become a combination of dashboards of aggregated engagement and metrics (e.g., looking at conversion rates between screens), customer support tickets, and one-off user research, conducted by user research, product marketing or marketing research.

In the early days of transitioning Uber into a superapp, our research surfaced several logical reasons for superapps rising popularity in Asia and South America, one of the most common reasons being limited device storage. Fewer apps meant less storage required. But talking directly to customers, a very different pattern emerged. Sure, space mattered - but no one obsessed over it. What got consumers pumped up were the rewards programs. I'll never forget how one consumer passionately described how he had migrated his entire family to the local superapp and had a weekly ritual to allocate the points back to his children as allowance, shares Mads.

In B2B companies, customer contact is often owned exclusively by account executives or relationship managers who maintain individual customer relationships. They frequently interact with customers, but mostly from a sales or support perspective. Product requirements are delivered second-hand back to product teams mostly in the context of support fires or customer requirements surfaced at contract renewal negotiations.

Tools for user feedback

Look for platforms that allow for granular targeting of your audience and video-sharing capabilities - there’s a lot of non-verbal communication in user feedback. It's not just what users say but also what excites them and causes them to interrupt with questions or ask for clarifications. A few platforms we’ve had success with are:

• Maze or Usertesting are full-service platforms that allow you to specify a specific consumer or B2B buyer and lets you bring a demo or an artifact for prospective customers to react to.

• You can also string together Prolific, which enables access to a representative sample of people to survey, and then leverage Hotjar to demo real users interacting with test versions of your pages.

Once you get customers onboarded, many startups create Slack, Whatsapp, or Discord groups with their first customers to get immediate and direct feedback. 

No matter the tools you use for talking with customers, ensure that they are less numerical and more qualitative. Numerical data is useful for making simple either/or decisions: A/B tests, signup flow optimization, or deciding on one logo over another. A qualitative understanding of your customers is what will help you figure out what options you should be testing and building to begin with.

In summary, here are the three main things we recommend:

1. There is no such thing as meeting your customer too early: Test positioning, mocks & distribution before you build and test your product

2. Use a prototype in your customer interaction, so you can discuss the solution rather than the problem.

3. Reinforcing that direct customer interaction is a core part of the job for product and engineering leaders as you scale and staff up customer-facing roles in research, marketing & sales.

Many teams hesitate to copy competitors or industry best practices. In an environment where innovation and creativity are valued, copying feels like cheating.

In most forms of racing, competitors will draft behind the leader, conserving energy while letting the leader deal with the headwind. Then, at the right moment, the drafting racer will slingshot past using their reserved energy. Winning product teams do something similar - they ruthlessly copy undifferentiated features from competitors and best practices, drafting off the leaders. This lets them conserve resources to focus creative efforts on the features that will allow them to slingshot past the competition by delivering unique value.

For example, Snapchat pioneered the "stories" format, allowing users to post videos that disappear after 24 hours. When Instagram launched its "Instagram Stories" feature three years later, it was a nearly identical copy in function and name. Meta executives were completely unapologetic for what many saw as plagiarizing Snapchat's innovation. Instagram stories surpassed Snapchat stories within a year, and today Instagram has three times as many MAUs as Snapchat.

Reinventing every feature is a surefire way to slow down your velocity. Don’t reinvent your lead gen page, don’t create a new way to adjust settings, and don’t rebuild basic navigational paradigms. Sure, Snap created an entirely new interface - but is the novel navigation paradigm your competitive differentiator? If not, copy the established standard and move on to the things that truly make your product great.

Resist the temptation to make minor improvements as you copy commodity features. Though tweaks may seem like easy wins, they are usually predominantly a coping mechanism for teams to deal with the discomfort of copying. Any deviation is added effort for unlikely gains: The industry has already iterated basic features to a highly effective form with a high degree of user familiarity. 

Copying should extend beyond what's visible. A lot of application logic can be inferred and should be copied as well. On multiple occasions, I’ve seen teams build notification timing and rules from scratch when observing best-in-class apps would have allowed them to establish rough heuristics, building complicated timezone logic when they could simply have timed notifications at the same time as the last app open.

Lack of product leadership exacerbates the problem. Post-it note brainstorming has become routine rituals for big tech product leaders to secure organizational buy-in rather than spawn creative ideas. Gathering teams to ideate and cluster colorful stickies rapidly is fun and engaging. But without this ceremony, many leaders lack the tools to align and unify stakeholders. Once groups participate in these sessions, momentum overrides practicality - it becomes difficult to copy a proven idea instead of reinventing concepts, even if duplication would yield better outcomes.

Determine what elements must be innovative - focus your creative energy on those - and celebrate teams that copy everything else.

This is the 5th installment on moving fast; make sure to check out the previous posts: Treat your engineers as adults, Set deadlines, even if you have to make them up, Ask for weekly updates, Eliminate unnecessary A/B testing

The stereotype makes for very entertaining TV characters. While it's obvious to anyone working in tech that the stereotype doesn’t capture the diversity of real personalities, many non-engineering leaders still approach engineering teams with the stereotype as an unconscious bias. Their approach is well intended, but it increases the risk of failure and slows overall velocity - a few common failure patterns:

• In an attempt to not hurt engineering morale, tech initiatives that took a lot of engineering effort to build are extended longer life than the business warrants, or the narrative around failure is sugarcoated, resulting in wasted effort, focus and inaccurate lessons learned.

• In an attempt to shield engineering from presumed draining human interaction, engineering is cut off from direct customer interactions, instead having to rely on intermediaries in product management, marketing, or sales for customer feedback. As a result, engineering misses an opportunity to directly explore problem/solution space with customers to build better and more efficiently.

• In an attempt to make engineering more efficient, specs are as provided as bitesize Jira tickets without a broader context or longer-term plan. As a result, engineering cannot effectively platformize capabilities or build extensibility in the most efficient manner, resulting in slower overall velocity.

A common theme in the failure patterns is an attempt by outsiders to protect engineering efficiency or shield engineering from presumed lower-value activities.

Because engineering is the largest component of any software development project, it is often assumed that overall development progress is bottlenecked by engineering efficiency. However, this is often not the case - speed of executive decision-making, partner interactions, or product/design resources are frequently the true bottlenecks to technical progress. Let engineers manage their own time and decide what activities are high and low value.

The best leaders treat their best engineers as trusted partners and adults. They involve engineers early in key decisions to tap their expertise. They share customer reactions openly, both good and bad. They course correct quickly when data suggests a change in direction without sugarcoating the rationale. Great engineers want to solve real problems and build great businesses just as much as everyone else, and “protecting” engineering or development time is largely counterproductive.

This is the 4th installment of Moving Fast posts - make sure to check out the previous posts: Move Fast #3: Set deadlines, even if you have to make them up, Move Fast #2: Ask for weekly updates, Move Fast #1: Eliminate unnecessary A/B testing

However, if you narrow the target to what is within a product team’s control, you usually end up with an esoteric metric rarely understood outside of the team, nearly guaranteed to be disconnected from business outcomes.

A flavor of this failure pattern is tying product goals to A/B test results. In theory, A/B test results yield the most accurate impact measurement of product changes. In practice, setting goals based on A/B tests slows overall velocity, as teams are incentivized to set up tests purely for the sake of attribution and run obvious improvements as tests instead of full ramps.

I used to buy into the argument and I’ve set my share of esoteric product goals, but I stopped after seeing product teams celebrate narrow metric wins while the business struggled or neglected ramping successful tests after taking the a/b test win.

Now, I always push product teams to be accountable for full business outcomes, even where control is partial. I remind teams that the same standard holds for all other functions:

• Sales doesn't fully control closed won revenue.

• Marketing doesn’t fully control ROAS. 

• Talent acquisition doesn’t fully control hiring velocity.

• Etc.

Clear incentives and goals are critical for teams to stay focused. Eliminate one source of distraction by aligning goals to the outcomes that matter to business.

Take Uber, famously arriving just as smartphones and GPS went mainstream, letting you hail a ride with a click. What this narrative leaves out is that several other ridesharing startups preceded Uber, including Taxi Magic and Zimride. Uber was not the first to build ridesharing on mobile, but we were the best at executing on the opportunity. Before Calm, there was Headspace. Before LinkedIn, there was Viadeo and Xing.

As a founder, it's critical to recognize that simply being first is not enough. First-mover advantages matter only if you accrue a durable competitive advantage, like network effects or economies of scale in winner-take-all markets. More often than not, simply being first to market doesn't offer a meaningful edge.

Build the best product, create the best user experience, and execute better than your competitors. This topic and many more in my Slush ‘23 talk on scaling product advantages - watch below:

In my experience, this belief unnecessarily limits the talent pool. Many of the best product managers I’ve worked with came into the role with a previous career in a different function, and their functional experience helped them succeed at senior levels in product management.

The key to hiring from other functions is aligning the role's archetype with the candidate's experience.

A more detailed description of these archetypes can be found at the end of this article

I’ve found an archetype that segments based on how the manager interacts with the customer to be most informative. For example, growth PMs tend to take a pattern-based experimental approach to understand customer behavior, primarily viewing interactions through the lens of A/B testing results. Enterprise PMs, on the other hand, work closely with sales teams to gather customer input, rarely relying on A/B testing.

Other product manager segmentation approaches, such as those based on product lifecycle stages (i.e., "0 to 1" or "1 to 100"), I have found to be less valuable. These lifecycle-based categorizations are often too company- and lifecycle-specific to apply broadly to skill sets: A “0 to 1” product manager in a large organization with existing products and distribution exercises a very different muscle than the first product manager in a company with no existing products or distribution.

What about heads of products / chief product officers?

Would I hire someone from an adjacent function directly into a product leadership role? The answer is no, though I would still value their adjacent experience. Product leadership requires firsthand product management experience - any manager of product teams should ideally have been a product manager themselves. For hiring the very first product manager in a company, I’m very aligned with Ken Norton’s perspective in “How to Hire a Product Manager”

What is the difference between a consumer and a growth product manager?

I think this point is best illustrated with a visual. Behold, the Uber app built by a consumer PM (left) and a Growth PM (Right)

Archetype descriptions

Growth PM

Responsible for optimizing user engagement and retention across acquisition channels, websites, mobile apps, and other touchpoints. Leveraging user data and analytics, they identify high-potential customer segments and craft targeted messaging campaigns and personalized product experiences that hook users and convert them into loyal customers.

Consumer PM

Lives and breathes understanding user needs, attitudes, and behaviors. With a passion for product details that light up the consumer’s eyes, they balance user value and business goals to bring delightful experiences to market. The Consumer PM has their finger on the pulse of the consumer at all times. They translate insights into intuitive and appealing product experiences that align with consumer goals and influence behavior change.

Enterprise PM

Deeply familiar with the business landscape, they assess market opportunities and translate customer needs into valuable B2B solutions. Close collaboration with sales, customer success, engineering, and executives helps the Enterprise PM spearhead the development of products and features that solve real business challenges. With an entrepreneurial spirit, they build partnerships, platforms, and services to power business growth.

Data PM

Architects the analytics foundations that feed product decisions. With expertise in machine learning, optimization algorithms, and scalable data infrastructure, they enable fact-based product development. The Data PM builds self-improving systems that gather customer insights, run rigorous experiments, and manage complex data flows to power future-ready products. They generate knowledge and drive innovation by leveraging the latest data science capabilities within the organization.

Platform PM

Architect of internal innovation and efficiency. They create seamless technology products and systems for employees by breaking down silos and fostering integration. Whether designing intuitive internal tools, building a shared infrastructure, or enabling automation, the Platform PM balances user experience with business cohesion.

When done well, presentations can yield a very accurate picture of a candidate’s problem-solving, presentation, and facilitation skills – three of the most critical skills in product. Candidates tend to perform exceptionally well or very poorly, and the hiring team often leaves with a largely aligned perspective on the candidate.

Over time, I’ve refined a straightforward process for candidate presentations –

• Once a candidate clears the first round of interviews, I provide them with a take-home prompt and invite 3-5 panelists, typically the hiring manager and essential cross-functional partners, for a presentation and a discussion.

• I let the candidate decide on what materials to bring and explicitly make time management the candidate's responsibility.

Typically, the prompt looks something like this:

The candidate presentation is an important part of our hiring process. It gives you an opportunity to highlight your unique experiences and why you’re an excellent fit for the position. 

Brief bio (5 min): Tell us about yourself and why you are interested in [company]

Discussion Prompt (25 min): Our company is currently facing [a challenge], How might we further develop [our product] to solve this problem

Discussion (30 min): As you’re planning your presentation, leave about 30 min for Q&A at the end of the presentation.

The allotted time above is guidance, we look to you to manage time during discussion. The discussion will be attended by: [person 1, title], [person 2, title], [person 3, title]

If you have any questions, don’t hesitate to reach out to [recruiter] or [hiring manager]

Over the years, I’ve also developed a few best practices that I find yield much better discussions:

• Avoid generic prompts such as “Tell us about your favorite product” or “Tell us about a product you are proud to have shipped.” Generic prompts lead to shallow discussions because the interview panel usually lacks the familiarity to drive a deep discussion. Base the questions on specific problems your current company is facing, where the panel will have deep expertise and will be able to drive a rich discussion.

• Don’t encourage timeboxed preparation: I’ve seen prompts encouraging timeboxing (ie “don’t spend more than a few hours on this”). I don’t think this is good advice to give a candidate, candidates that ignore the guidance and spend the time they need usually perform better.

• Check-in with the candidate as they are working on the case: Doing a presentation as part of the interview loop might be a new experience for the candidate, so I like to check in with them to make sure they understand what we are looking for. 

• Minimize passive participants: I ask the candidate for permission to record the discussion; this allows you to relegate quiet participants to watch the interaction offline. This is particularly critical in virtual discussions, where you can spare the candidate from talking to a Zoom wall.

The skills tested in candidate presentations are highly relevant for on-the-job performance of a PM: Do they prepare well, think well on their feet, and facilitate a productive discussion? It's one of the best assessment instruments available—don’t skip it!

This week I had a discussion with 30 founders about early stage product development at the byfounders basecamp. I went over a list of symptoms of an organization lacking urgency, one being having no deadlines or milestones. This spurred a lively debate that lasted the rest of the session.  

My position is that organizations need committed deadlines for projects, even if they are “artificial” and not driven by any external event. A pushback on “artifical deadlines” represents a mindset problem with your product/engineering team that’s slowing them down. I was surprised by how controversial this viewpoint was – the arguments against deadlines included:

• Setting dates without a true need feels arbitrary, especially if someone lacking domain expertise sets them, like a CEO dictating timelines to engineers.

• It’s difficult to estimate work upfront accurately. As you dive into a problem, you frequently uncover unanticipated complexity that extends timelines.

• External dependencies outside of the team’s control make deadlines pointless. For example, you might rely on a partner to accomplish something without input on their schedule.

While understandable, these are not valid excuses for operating without deadlines. Declining to commit to timeframes because of uncertainty rewards the avoidance of hard choices and provides cover for undisciplined execution.

If you are uncomfortable self-imposing deadlines, have your team set deadlines and then monitor accuracy and build metrics around improving velocity. The discipline of tracking to fixed timelines, while difficult, accelerates organizations. Progress depends on committing to dates, holding people accountable, and driving the resolution of blocking issues. Deadlines may cause short-term pain but enable long-term speed.

The Minto Pyramid Principle offers a helpful framework for crafting effective summaries. While the original book (link) is lengthy and expensive, the core concepts are straightforward and can be learned from online summaries (this 8-minute YouTube video is a great start).

A few tweaks to the pyramid principle can greatly enhance written summaries. While examples often focus on strategy recommendations, the approach works for any summary, as demonstrated below.

Tweak #1: Represent the pyramid as indented bullets, with the conclusion as the first line in bold, supporting arguments at the first indentation level, and supporting data at the second indentation level:

We closed bug #3571 with minimal user impact

• We closed the bug within the SLA

  • The bug - a P1 - was closed in 36 hours

  • Our P1 resolution SLA is 48 hours

• The bug seems to be resolved

  • No additional user complaints since the fix was deployed

  • Upon investigation we found no log events related to the bug - we also deemed that changing logging was unessessary moving forward

• User impact of the bug was minimal

  • We received 15 user complaints related to the bug

  • The 15 tickets represented 0.01% of total ticket volume over that time period

Tweak #2: Collapse the supporting arguments and data into a two-layer summary. Eliminate qualifying verbs (e.g., "minimal," "seems to be," etc.) and replace them with concrete supporting data. Re-order secondary bullets based on importance.

We closed bug #3571 within SLA; 15 users impacted (0.01% of all incidents)

• 15 user complaints related to the bug (.01% of incidents)

• P1 bug closed within 24 hours (36 hour SLA)

• No additional user complaints since the fix was deployed

• Upon investigation we found no log events related to the bug - we also deemed that changing logging was unessessary moving forward

Tweak #3: Eliminate data points that aren't essential to the conclusion. In fact, don’t pursue or investigate data points that aren't required to make your case. This step can be highly timesaving if done upfront. The point of the Pyramid Principle is not to create a formal logic proof; in real life, circumstantial facts are often enough to support your main point.

We closed bug #3571 within SLA, 15 users impacted (0.01% of all incidents)

• 15 user complaints related to the bug (.01% of incidents)

• P1 bug closed within 24 hours (36 hour SLA)

• No additional user complaints since the fix was deployed

I’ve found that asking project teams for a brief weekly update forces timely escalation and provides clarity on milestones. I have written my fair share of weekly updates, and I used to dread them as they would inadvertently evolve into lengthy updates with a very low signal-to-noise ratio.

To avoid this, I’m extremely prescriptive about what information is helpful to share in a weekly update. My preferred format is below:

***

If you have landed here, mads@ has likely asked you to send weekly updates. What you are doing is most likely:

• Critical to Calms overall success

• Highly cross-functional

The ask is not a judgment on progress to date or an indirect critique of progress. In a fast-moving environment, everyone quickly gets fragmented, and a ‘push’ update system such as a simple email has been a very effective way to drive clarity and ensure executive support for your initiative.

A great weekly update is:

• Short: 3 Bullets only (see template below), link to any details.

• Frequent: Always weekly on the same weekday – free choice on which weekday

• Anchored in top-line metric: Start with top-line metric, no need to call out small movements.

• Sent by anyone on the working team: The Sender does not have to be the DRI or the most senior person in the working group.

To avoid weekly updates becoming too high effort / low impact, I’m providing a specific template I would like you to follow:

Template

To: [distribution list]

Subject: [Name of effort] Weekly (date)

Body:

• Absolute key metric, WoW, YoY & any commentary if movement is meaningful

• Key milestone achieved this week

• Key milestone for next week

A good weekly update

To: leads-distro

Subject: [project alpha] Weekly Update (1/3/22) 

Body:
700 weekly widgets sold, -1% WoW, +100% YoY
Launched the widget 2.0 in Metropolis on 1/2 (readout)
Key milestone next week: Complete user research on widget 3.0

A subpar weekly update

To: Joe, Jim, Jane <- create a google distro and let people self-enroll/unsubscribe. Also gives you email history for free for new folks joining after you start sending updates

Subject: Weekly update <- with no distinct identifier in subject email rules break easily when a new sender takes over

• We saw 10% increase in metropolis conversion test <- partial metric, base rate bias. Always refer to the top metric in absolute terms

• Product <- bullets should not be a roll-up of all functional activities, focus on the most important milestone

  • We met and discussed the next city to launch in<- outcomes only as milestones, ‘plan for a plan’ or meetings/discussions are not an outcome

• Marketing

  • Good progress on hiring <- dimensionalize where possible. Use a numerical quantifier instead of ‘good’

Not all B2B value props are created equal—the highest-quality value propositions directly help companies generate revenue. Lower down are value propositions that help companies save costs, and at the bottom are value propositions that offer time or resource savings. Within a company, it is usually possible to pay to get more time or resources. However, turning time savings directly into revenue opportunities is often impossible.

Aim to build a value prop of as high quality as possible. It’s not always possible to tie your product to revenue generation. Still, you should at least aim to concentrate time savings into money saved, usually by focusing on automating entire workflows or job functions rather than incremental efficiency gains.

Watch out for value propositions not anchored in saving time, money, or making money. These vague value props often sound enticing, but they leverage shorthands such as “being essential” or “being a one-stop shop” to obscure where the value lies. They are often used to camouflage that no tangible value is delivered.

Look for opportunities where problem spaces increase in value proposition quality over time. A few years back, SOC2 compliance certification shifted up the hierarchy once many companies began requiring it from their vendors. This elevated SOC2 from a cost/compliance issue into a sales revenue enabler. Companies like Vanta and Drata recognized this up-leveling and enabled rapid SOC2 certification as a service. Identifying similar evolutions and enabling value at the next quality tier often unlocks new growth.

Yet nailing a small set of priorities is one of the most elusive steps in product planning. Unlike the first phase of planning, which usually involves inclusive, fun brainstorms on what is possible, the final phase involves the much less fun and rarely inclusive step of deprioritizing most of the exciting new ideas to drive focus on fewer things done well.

At Uber, I was introduced to an approach that allows for focused prioritization discussions even in very large forums. Its a high energy, fun, and much more inclusive approach that now exists as a Coda sheet:

The Friendly Feud Game (Coda)

The most helpful cancelation surveys follow three basic principles:

1. Keep it short and simple to drive as high participation as possible

2. Include at least one free-text answer because your customers may tell you something you were not aware of

3. Do not make the survey anonymous so you can tie the customer response to how the product was used

​The third principle is frequently missed, but critical to get actionable insights. Below, I’ll share three examples of how an understanding of product engagement combined with the cancelation survey can yield powerful insights

For the customers where product is ‘too expensive’ or provide ‘too little value’

Some customers will state that they canceled because the product was too expensive. Without the ability to identify the cohort, you will not be able to price discriminate (beyond using the cancelation as a signal). More importantly, price may not be the true underlying issue – perhaps your customers did not discover and use the features that are worth paying for:

In the chart above, we see that customers that indicated the product was too expensive did not find and use ‘feature A’. If you believe the ‘feature A’ is important for willingness to pay, you could invest in making the feature more discoverable rather than lowering the price. Alternatively, you could create a product option without feature A marketed to this cohort at a lower price point.

For the customers where the product ‘didn’t meet expectations’

Some customers will state that they canceled because the product did not meet expectations. A natural follow-up question is if this cohort had expectations set differently. For example, you could look at the acquisition channel of customers that churned:

In the chart above, we see that customers with misaligned expectations primarily came through ‘Email Campaign B’. Instead of making broad improvements, we can focus on ensuring messaging and flow of ‘Email Campaign B’’ is in line with other channels.

For the customers where the product ‘was confusing’

Some customers will state that they canceled because the product was too confusing. Without additional information you could invest in support materials or a more extensive onboarding flow. However, the confused cohort may have taken a specific path through your product that is broken or confusing:

In the chart above, we see the majority of confused customers went to Feature C in their first session as opposed to feature A and B from the main page. This understanding allows us to focus on the specific flow from the main page to Feature C to identify any potential issues.

The examples above are by no means comprehensive, but they serve as an illustration that the cancelation survey results are often only the beginning of a string of subsequent questions and learnings that can only be possible if you know the trifecta of the ‘why’ from the survey, ‘who’ the survey taker is and ‘how’ she used your product.

Recently, the Scandinavian online auction site Lauritz.com got into hot water when a newspaper found the bidding behavior on the site to be suspiciously lopsided. The newspaper scraped the auction site and revealed that while the average user participated in 3 auctions on Lauritz.com, the 10 most active users participated in 370,000 auctions, roughly 10% of all auctions (story here). The story serves as a good reminder that online user behavior is rarely normally distributed and that looking at average user engagement is not very meaningful.

As an example, we can look at GitHubs user engagement data: In 2015, the average active GitHub user pushed code to the repository ~24 times / year. Without additional detail, it is easy to imagine that most users pushed code between 20 and 30 times, with roughly half the users pushing more and roughly half the users pushing less, but what emerges in the distribution is a completely different picture:

Distinct cohorts emerge in the histogram, most notably the 45% of users that did not push any code at all and the 9% of users that pushed more than 51 times. The latter cohort accounts for 79% of all push events in 2015. The ‘average user’ turns out to be a minority: Only 4% of all users push code between 21-30 times/year.

In consulting, we often use the Pareto principle of ‘80/20’, meaning 80% of the activity is accounted for by 20% of the users. However, online user engagement can be even more lopsided. In the case of Github, the top 1% of users account for 45% of all push activity and the top 0.1% of users account for 17% of all push activity. When it comes to online behavior, ‘45/1’ is the new ‘80/20’.

So what does this mean for your product strategy?

Instead of designing your product to the ‘average user’, you have to identify the key usage cohorts and tailor your product strategy accordingly. In the extreme, you will have two cohorts:

1. The long tail of highly engaged users (e.g., the extreme bidders at Lauritz.com or the top 1% of code pushers on Github)

2. The unengaged users (e.g., the 45% of Github users who did not have a single push event in 2015)

For the long tail of highly engaged users: Are these your most valuable users or your worst offenders?

Establish what the high engagement users are trying to do through further analysis or interviews and make up with yourself if the behavior is in line with your vision for your product. In marketplaces, like Laurtiz.com or Github, one approach to establishing if the behavior is ‘good’ or ‘bad’ is to look at the amount of value created on the other side of the marketplace. Specifically, how many downloads are generated by the code uploaded by the top 1% of GitHub code pushers.

If you find that the highly engaged user behavior is good, then you need to account accordingly in your roadmap prioritization. Even though the cohort may be a minority, you want to prioritize features for this cohort if they deliver a lot of value to your product. The behavior itself may provide a good initial idea of features that would be valuable, e.g., Lauritz.com could consider investing in features for large-scale batch bidding.

If you find that the long tail of highly engaged users are your worst offenders, then you can curb the usage. The curbing does not have to be a hard cut-off: You could establish paywalls at high levels of usage, which will likely both curb usage and allow you to extract value from the high engagement.

For the unengaged users: How far did they get in your product?

For the users who did not engage at all, you need to pinpoint exactly where they disengaged from your product. A funnel of the the activity leading up to that engagement can be helpful to reveal where your product might be falling short (did they discover your most valuable feature)? In the case of Github code push, one could establish how many of the users created an account, how many set up a local repository, how many forked a branch of code, etc. Product improvements and re-engagement campaigns should be oriented around the largest drop-offs in the funnel leading up to the desired engagement.

In summary, recognize that online user engagement can be extremely lopsided and tailor your product strategy to your largest cohorts’ activity levels instead of designing for your ‘average user’.

Revenue growth is a good indicator that your SaaS business is doing well, but not all revenue growth is equally sustainable, and it's important to understand what drives growth. There are fundamentally only three ways to grow revenue:

1. Customers paying more per month (good): Growth driven by price increases/conversions to higher priced SKU’s. Continued growth requires you to continue to increase pricing/conversions.

2. More customers subscribing (better): Growth driven by increased customer acquisition. Continued growth requires you to identify and scale acquisition avenues.

3. Customers subscribe more months (best): Growth driven by increased retention. This indicates better product market fit, which will likely continue to drive growth without further action.

Breaking revenue growth into the three drivers of monetization can provide an early warning system of slow down in growth, as illustrated below:

At first glance, our business looks healthy, with 30% overall revenue growth. However, the revenue breakdown reveals the following:

• Growth this year was driven by an increase in revenue/month/user (e.g., price increase) and a growth in customers up for renewal (e.g., previous spike in acquisition)

• New user acquisition dollars grew slower (10%) than the recurring user base growth (25%), and the recurring customers are subscribing fewer months, indicating deteriorating product market fit.

If we play this movie forward, we should expect to see much lower growth the following year.

In summary, not all revenue growth is created equal, and understanding the source of growth can help you provide an early warning system for your SaaS business.