Menu

Posts tagged “product strategy”

Some Products Just Aren’t Big Companies

This take on the Pocket shutdown resonates with me real hard:

“What began as a read-it-later app”, they assert, “evolved into something much bigger.” That was the whole problem: the mistake that led ultimately to this “difficult decision” by Mozilla. Pocket was a good tool. Its integration with Kobo, another excellent tool, made it that much more valuable to users like me. We didn’t need “something much bigger”. But by trying to turn Pocket into something much bigger, Mozilla actually killed it.

I feel like nothing has changed since I wrote about this kind of thing in… 2012:

This is the core of the disappointment that many of us feel with the Sparrow acquisition. It’s not about the $15 or less we spent on the apps. It’s not about the team’s well-deserved payout. It’s about the loss of faith in a philosophy that we thought was a sustainable way to ensure a healthy future for independent software development, where most innovation happens.

Some Products Just Aren’t Big Companies

Regarding "missed" and "slipped" deadlines

I really like Basecamp’s concept of “Hill Charts”. The gist of it is that each project we work on has two distinct phases: a “figuring it out” phase and a “making it happen” phase:

To quote from their post about it:

First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.

Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.

“Figuring it out” is full of uncertainty, unknowns, and problem solving. “Making it happen” is all about certainty, confidence, and execution.

I bring this up because one of the issues with quarterly planning cycles and committing to due dates on that cadence is that teams are often asked to commit to dates during the “figuring it out” phase. There’s a lot of uncertainty and unknowns, so teams have to make best guesses. The problem with this is that these do not reflect what Cagan calls “high-integrity commitments”:

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important, if what we deliver will actually solve the problem for the customer.

So what inevitably happens is that, for a lot of projects, the date that teams provided “slips”. I believe this language matters, and I think by framing it this way an org tells teams they did something wrong. But the irony is that in the majority of cases, if teams move a date after they reached the “top of the hill”, they are doing the right thing for the business. They are saying that they have now figured out all the unknowns and uncertainties, and they are ready to make a high-integrity commitment. Again, here is Cagan:

So the compromise is simple. The product team asks for a little time to do product discovery before commitments are made, and then after enough product discovery is done to consider the risks, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

I think it’s important to encourage behavior that does the right thing for customers and the business. The right thing would not be to try to cut corners to meet a date that was committed to during a “figuring things out” phase. I also don’t believe the right thing is to inherently communicate to teams that moving a date once they reach the top of the hill means they “missed” a commitment.

I think we should be very clear about the nature of commitments when we make them. What is our confidence in our dates? Are we still figuring things out? Or are we at the top of the hill and ready to make a high-integrity commitment? The health of any Product org can be improved if we say that it’s ok to communicate what we think we can accomplish early on in the quarter, and move to high-integrity commitments once teams reach the top of each project’s hill.

How to Make Planning Better

Lots of great planning advice in this First Round article. There are two things related to Strategy that I especially like. First, this definition (Strategy is not a vague vision statement!):

Strategy is the sequencing of how you take a very long-term end goal and break that down into more digestible components. Done right, it gets you a really clear picture of what’s in your long-, mid-, and short-term plans, where you stack up in the market, and how you’ll win.”

And then, the importance of org design in executing that strategy well:

Org design is how you deliver on your plan. Instead of meticulously planning all of the ‘what,’ the right org design will give you the ability to hand a talented group of people a new goal, and have them continuously come up with the best way to achieve it.

The post also covers another topic I’ve been thinking about a lot, which is the cadence for planning, and how to make the quarterly (or however often you do it) planning cycle less painful/stressful. We’re in our annual planning cycle right now—once we’re done I will write a post that touches on these topics, and more.

What does a date actually mean?

James Stanier has a good argument for why deadline-driven development is so… difficult:

Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.

What’s the “something different”?

So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.

This is why I will always advocate for time horizon roadmaps.

A Deadly Gravitational Pull in PLG B2B: Individual-Centric Experiences

Elena Verna on the importance of focusing on team experiences in B2B products:

The key to any successful B2B Product-Led Growth (PLG) strategy lies in connecting end-user adoption to enterprise-level deals. But because B2B PLG often looks like, smells like, and acts like consumer product, it pulls product and marketing teams into a deadly gravitation pull of crafting consumer-like experiences focused solely on the individual value. While acquiring individual users is a natural first step, failing to consider the dire need to connect that individual to a team and a company level value WILL sabotage your future growth.

Thoughts and takeaways from the Lenny and Friends Summit

I spent the day at Lenny’s Summit with over 1,000 other product people. The line-up of talks was fantastic, but you never know how it’s really going to go. I am happy to say that the hit rate of good talks was quite a bit higher than some other conferences I’ve been to. I tried to write detailed notes, and below are my summaries and takeaways from 4 of the talks that I enjoyed the most.

There were also a couple of interviews that were really great—Lenny interviewing Shreyas Doshi, and Sarah Guo interviewing Mike Krieger and Kevin Weil (pretty cool to see two major competitors play nice on stage together)—but those were a little harder to summarize so I gave up on note-taking and just listened.

Product Management is Dead (or Will Be Soon) by Claire Vo (LaunchDarkly)

I’ll start with this one since the title is obviously pretty controversial. I expected to disagree with a lot of it, but it was actually really measured and interesting. Claire focused on the rapid transformation of product management due to AI, and outlined the need for product leaders and teams to adapt to these changes. She highlighted the evolving nature of product roles, driven by automation, and offered insights on how to prepare for an AI-powered future.

Key Insights:

  • AI Will Transform Product, Design, and Engineering.
  • AI is advancing faster than anticipated, reducing the need for traditional product management tasks and roles.
  • The key challenge is to not be caught off guard by these changes.

3 Requirements for an AI-Powered Team

  • Automate to Speed Up Delivery
    • Use AI to accelerate common tasks such as:
      • Drafting documents, collecting feedback, writing updates, and creating agendas.
      • Monitoring goals (OKRs), tracking competitors, and preparing for interviews.
      • Creating customer stories, enhancing presentations, and explaining product functionality.
    • Aim to achieve 75% progress quickly with AI assistance, rather than striving for 100% automation.
  • Add New Skills and Expand Capabilities
    • The future of product management will include people with technical backgrounds (e.g., engineers) who use AI to gain product skills.
    • AI will enable individuals to learn and contribute across multiple domains.
  • Multiply Your Impact by Teaching AI Skills
    • Encourage your team to embrace AI for building products and improving efficiency.
    • Normalize the use of AI in everyday tasks to enhance overall team performance.

Impact of AI on Product Teams

  • Time & Creativity
    • With product work taking less time and requiring less mental effort, product teams can invest more time in creative problem-solving and direct user engagement.
  • Fewer PMs Needed
    • AI will consolidate previously distinct roles, leading to a new model where one person, with the aid of AI, can manage design, engineering, and product functions—creating an “AI-powered triple threat.”

Evolution of Roles

  • From Product Triad to AI-Powered Generalists
  • The traditional “product triad” (PM, designer, engineer) is evolving into roles where AI-empowered generalists can handle multiple disciplines.
  • Teams will need to adapt to this shift without being intimidated by the collapse of traditional job boundaries.

Takeaways for Product Leaders

  • Prepare for the New World of AI-Driven Product Management
    • Acquire more commercial and technical skills.
    • Learn to budget for AI tools and agents that enhance hiring and team structure.
    • Explore new team topologies beyond the traditional triad model.
  • Start Adapting Now
    • AI-driven changes will happen fast. Begin integrating AI into team processes and management strategies immediately.

Summary

  • Product teams must embrace AI now to remain competitive and efficient.
  • AI will consolidate roles, but with the right approach, it won’t break your team—rather, it will strengthen and streamline it.
  • Product leaders must learn to navigate and manage this new, AI-driven world.

How to Do the Product Review Right by Yuhki Yamashita and Mihika Kapoor (Figma)

This was, unexpectedly, probably my favorite talk of the day. It was just so well executed: a CPO and IC PM riffing off the experience of doing product reviews. They offered a new perspective on product reviews, emphasizing that their true purpose is not about decision-making but about building trust with stakeholders. They shared key insights on how PMs can run effective reviews by shifting their focus from trying to impress to fostering confidence in their judgment and direction.

Key Insights:

  • Product Reviews Are Not for Making Decisions, but for Building Trust
    • Traditional advice for product reviews focuses too much on pitching ideas and covering every detail, leading to ineffective presentations.
    • The real goal is to gain trust, which allows PMs the time and space to execute on what truly matters—building great products.

What PMs Are Typically Told (but is Ineffective):

  • Build up Context First
    • Most attendees won’t care about background details.
  • Cover All Bases
    • Trying to explain everything dilutes your message—“if you say everything, they hear nothing.”
  • Circle Back Later if Unsure
    • Deferring answers creates uncertainty and erodes confidence.
  • Make a Big, Bold Pitch
    • Emphasizing a grand vision over clarity and precision can backfire.

What PMs Should Actually Do (for Winning Trust):

  • Lead with the Punchline
    • Present the most controversial or important point first. This sparks honest reactions early and avoids drawn-out discussions.
  • Create an Internal Brand
    • Use humor or memorable analogies (“Make a meme”) to spread your idea and make it stick with your team. This can generate internal momentum.
  • Share Your Gut Feelings
    • Don’t wait for perfect data. Share your instincts and anticipated learnings upfront, demonstrating decisiveness and confidence.
  • Be Your Own Biggest Critic
    • Show you’ve thoroughly considered all options and potential challenges. Structure your presentation as:
      • Pain Point → Solution → Proof Point
      • Lay out the solution space and address anticipated concerns to preempt pushback from leadership.

Summary:

  • The Product Review Isn’t the Most Important Part
  • While product reviews feel critical, what matters more is what happens outside the review. Building trust during the review gives PMs the freedom to focus on what truly counts: creating and delivering valuable products.

By focusing on trust-building rather than decision-making, PMs can create more impactful product reviews and set the stage for successful product development.

How to Win Friends and Influence Decisions by Julie Zhou

Julie outlined a structured approach for moving from having a strong personal opinion to shaping better collective outcomes in decision-making. She provided practical steps to navigate disagreements and arrive at informed, collaborative decisions that benefit the entire team.

Key Steps:

  • Step 1: Draw a Circle Around the Team, Not Yourself
    • Frame the decision-making process as a collaborative effort, not a personal mission to convince others.
    • Encourage open dialogue by focusing on shared goals: “What we really want is X, so let’s explore various ideas.”
  • Step 2: Assume Everyone Sees Part of the Truth
    • Use the analogy of the “blind men and the elephant” to acknowledge that everyone holds part of the truth.
    • Differences in perspective should be seen as valuable pieces of a larger, more cohesive understanding.
  • Step 3: Uncover the Truth from Multiple Perspectives
    • Facilitate discussions that explore the rationale behind each person’s perspective. Ask questions like:
      • “What would have to be true for us to believe this is the right approach?”
      • “What data or scenario would convince us that the other option is better?”
  • Step 4: Turn the Problem Into a Data-Driven Question
    • Shift the debate to evidence-based thinking. Seek out relevant data by asking:
      • “How can we know that it’s really true that…?”
      • “What evidence do we already have, and what do we need?”
  • Step 4b: When Data Isn’t Available, Rely on People
    • If data is unavailable, delegate the decision to someone who is deeply invested, knowledgeable, and trusted to make the best call. Trust the judgment of someone with the right context and skills.
  • Step 5: Review and Learn from Decisions
    • Regularly revisit past decisions to assess their outcomes. This practice helps identify whether decisions led to success or failure.
    • Set calendar reminders to review decisions at regular intervals and document areas of disagreement or learning.
    • The layers of learning from past decisions:
      • What did we learn about our customers and their needs and preferences?
      • What did we learn about the levers that drive our product usage?
      • What did we learn about the best measurement proxies for our goal?
      • What did we learn about making better and more efficient decisions?
      • What did we learn about the quality of our individual judgments?

This framework emphasizes collaboration, evidence-based decision-making, and continuous learning to improve both individual and team outcomes.

How to Craft an Elite Career by Nikhyl Singhal (Former VP of Product at Meta)

This talk offered insights on managing a successful career, viewing it as a product to build over time. Nikhyl provided a framework for progressing through different stages of a career while highlighting key pitfalls to avoid and strategies for developing a strong personal brand and maintaining balance.

Key Insights:

  • Your Career is Your Most Important Product
    • Careers span multiple jobs, typically 2–3 years each, which can result in 20–30 jobs over a lifetime.
    • Treat your career like building floors in a structure, with distinct phases to navigate.
  • Career Phases:
    • Foundational: Gaining experience and stories.
    • High Impact: Driving measurable value and influence.
    • Joyful Giving: Contributing to others and sharing your knowledge.
  • Collect Stories and Build Expertise
    • Aim to accumulate stories from diverse experiences (different companies, markets, and cultures).
    • The ability to say, “I’ve seen this problem and here’s how I solved it,” is key to advancing.
    • Continuously ask yourself: What story will I tell in 12 months? If it’s the same as today, it may signal career stagnation.
  • Establish a Strong Reputation
    • Develop a reputation of hard work, being a team player, and offering strong opinions that are open to change.
    • Your reputation today forms the brand that can open future opportunities.
    • Focus on being a builder and a giver—someone who elevates others rather than acting solely for personal gain.

Avoiding Leadership Pitfalls

  • Avoid Burnout
    • Over-investing in work can lead to resentment when sacrifices (e.g., missed family events) aren’t reciprocated.
    • Enforce boundaries early to prevent burnout—success often leads to more responsibilities without additional rewards.
  • Beware of Superpower Shadows
    • Identify and manage the downsides of your strengths. For example, being great at storytelling might come at the cost of overlooking important details.
    • The skills that got you where you are may not be the ones that propel you forward.
  • Recognize You Are Not Alone
    • Build a network of product leaders for mutual support and collaboration. Helping others is a key part of career longevity and satisfaction.

Summary

  • Divide your career into phases: foundational, impactful, and giving.
  • Accumulate diverse stories that show your growth and problem-solving abilities.
  • Your brand is built on your current reputation—focus on being a builder and contributor.
  • Set and enforce boundaries to avoid burnout and resentment.
  • Leverage your superpowers, but be mindful of their potential downsides.
  • Cultivate a community of peers for long-term support and shared learning.

By focusing on storytelling, reputation-building, and self-awareness, you can craft a career that grows over time, with a strong foundation in both personal and professional fulfillment.

Talking to customers

Oh my, Justin (from my favorite newsletter platform Buttondown) nails it here:

Customers make for good historians but poor futurists, and certainly they won’t do the hardest and most important job of identifying your leverage points for you.

That was your shot. Here’s your chaser:

None of this is to say you shouldn’t talk to customers: you should! But it should be neither the first nor the last step in your process: if someone needs to talk with people to figure out what to build next, it means they have insufficient vision; if someone needs to talk with people to figure out if something is truly ready for GA it means your org has insufficient conviction and process.

Heartbeats: keeping strategies alive

I like this idea from James Stanier on how to make sure that product strategy doesn’t die the moment it’s created:

One way to do this is to create a regular heartbeat for your strategy. The duration of this heartbeat is up to you, but aligning with one of the larger cycles of the year is a good bet: for example, perhaps you could do it quarterly or biannually. The heartbeat is a communication that looks back at the strategy, recaps the key points, and then shows how it has been implemented in the time since the last heartbeat. It’s a chance to show how the strategy is living and relevant, and that it’s not just a document that was written once and then placed on the shelf.

Why GitHub Actually Won

This is a really interesting overview and perspective by one of the co-founders of GitHub:

So, to sum up, we won because we started at the right time and we had taste. We were there when a new paradigm was being born and we approached the problem of helping people embrace that new paradigm with a developer experience centric approach that nobody else had the capacity for or interest in.

The whole post is worth reading for the history and all ways things just went right for GitHub.

Executive translation

This is excellent advice from Will Larson:

Many high-agency managers try to prevent executives from doing silly things, but it’s almost always more effective to translate their energy for a silly thing into energy for a useful thing. It also leaves the executive feeling supported by your work rather than viewing you as an obstacle to their progress.

He shares some practical examples in the post to illustrate the principle. Also relevant—Casey Winters’s story about executives sometimes wanting their rounded corners on images:

You are going to run into founders, CEOs, execs that want their “corners”, or seemingly irrational markets, product, features, etc. And it’s going to be your job to make those things happen. As a former product leader, I think every CEO or founder should be trusted when they ask for a corner. Now, if they’re doing it all the time, it might just be a bad leader, and you should get a new job. But I have learned to respect there is a thought process I can’t always see, an important reason they can’t always share with me that may make this the right call. So, now I just label certain ideas as corners in the strategy to teams. I can’t exactly lay out all the reasons this makes sense to do now or agree with the ones I’ve heard, but we’re going to do it anyway, and hope it’s the right thing.