Menu

Posts tagged “product strategy”

Tony Fadell on the role, responsibilities, and importance of product management

I recently finished Nest creator Tony Fadell’s book Build: An Unorthodox Guide to Making Things Worth Making (I highly recommend it). I wanted to spend a few moments reflecting on the chapter on product management because it is just so good. I haven’t read something that made me feel this inspired about the importance of what we do in a long time.

First, it’s always fascinating to me how different people define this undefinable role. Here’s what he says:

A product manager’s responsibility is to figure out what the product should do and then create the spec (the description of how it will work) as well as the messaging (the facts you want customers to understand). Then they work with almost every part of the business (engineering, design, customer support, finance, sales, marketing, etc.) to get the product spec’d, built, and brought to market. They ensure that it stays true to its original intent and doesn’t get watered down along the way. But, most importantly, product managers are the voice of the customer. They keep every team in check to make sure they don’t lose sight of the ultimate goal—happy, satisfied customers.

One definition is never enough, though. Every product management book has a few “oh, but also…” sections, and this one is no different:

Product managers look for places where the customer is unhappy. They unravel issues as they go, discovering the root of the problem and working with the team to solve it. They do whatever is necessary to move projects forward—that could be taking notes in meetings or triaging bugs or summarizing customer feedback or organizing team docs or sitting down with designers and sketching something out or meeting with engineering and digging into the code. It’s different for every product.

It’s interesting to read his perspective on product management vs. product marketing (especially since I am also currently reading Martina Lauchengco’s SVPG book Loved: How to Rethink Marketing for Tech Products, which has a decidedly different view on this role):

Most tech companies break out product management and product marketing into two separate roles: Product management defines the product and gets it built. Product marketing writes the messaging—the facts you want to communicate to customers—and gets the product sold. But from my experience that’s a grievous mistake. Those are, and should always be, one job. There should be no separation between what the product will be and how it will be explained—the story has to be utterly cohesive from the beginning.

But my favorite parts of the chapter are the ones that made me feel. There is so much content out there about just how hard the job of product management is, and so little about what an exciting and special role it is. Tony gets to the heart of what makes this work worth doing:

Sometimes they’ll have the final opinion, sometimes they’ll have to say “no,” sometimes they’ll have to direct from the front. But that should be rare. Mostly they empower the team. They help everyone understand the context of what the customer needs, then work together to make the right choices. If a product manager is making all the decisions, then they are not a good product manager.

And:

So the product manager has to be a master negotiator and communicator. They have to influence people without managing them. They have to ask questions and listen and use their superpower—empathy for the customer, empathy for the team—to build bridges and mend road maps. They have to escalate if someone needs to play bad cop, but know they can’t play that card too often. They have to know what to fight for and which battles should be saved for another day. They have to pop up in meetings all over the company where teams are representing their own interests—their schedules, their needs, their issues—and stand alone, advocating for the customer.

He’s right about how difficult the role is to hire for, though:

This person is a needle in a haystack. An almost impossible combination of structured thinker and visionary leader, with incredible passion but also firm follow-through, who’s a vibrant people person but fascinated by technology, an incredible communicator who can work with engineering and think through marketing and not forget the business model, the economics, profitability, PR. They have to be pushy but with a smile, to know when to hold fast and when to let one slide. They’re incredibly rare. Incredibly precious. And they can and will help your business go exactly where it needs to go.

Yes, I know—I just quoted someone who called us “precious,” which is a little obnoxious. But I spend enough time hand-wringing about how we shouldn’t consider ourselves so special (see, for example, The dangerous rise of “crazy-busy” product managers) that I’m going to give myself a freebie here.

Anyway, you should read the book. I have some issues with the parts that lean heavily into hustle culture, but if you ignore those bits it is really fantastic. The ending made me tear up a little bit…

In the end, there are two things that matter: products and people. What you build and who you build it with. The things you make—the ideas you chase and the ideas that chase you—will ultimately define your career. And the people you chase them with may define your life.

Product leaders: don't lose your proximity to the heart that keeps your business alive and well

David Hoang wades into the treacherous waters of the Should managers be technical? debate, and IMO comes out safely on the other side. I really like the 3 points he makes towards the end to articulate his point of view. I won’t spoil it because it’s worth reading the whole post. There’s one other bit I wanted to comment on, though:

The key roles of managers are to set expectations, ensure the team is operating efficiently, and maximize the output of the people on your team. In order to develop people, you must have a certain level of understanding of what skills are needed for people to be successful. However, as you progress in your career, there are going to be different org structures in place where it’s relevant. If you’re a Chief Product Officer, they likely have a more broad level of understanding of other functions outside of their domain and will put leaders in place who have the depth of knowledge in those areas.

I agree with the point that as you move into a leadership role, you can’t be as involved in the technical details of the product as much as you used to. But one mistake I see leaders make is to extract themselves completely from the product. And this becomes a bigger problem, especially in larger organizations. The further away the leadership team are from customers and the product, the more difficult it becomes to create product strategies that provide real customer (and business) value. Without the context of how the product works—and more importantly, how customers use the product—you cannot have a strategy that fully takes customer value into account. You end up with strategies that are too heavily skewed towards business value. A good product strategy balances both those things.1

So, leaders: Spend time with your product at a deep technical level. Download Postman and interact with the API. Ask to be invited to a few customer calls each week, and attend at least one every two weeks. Don’t lose your proximity to the heart that keeps your business alive and well.


  1. Side note: last week I started a new series for the Elezea newsletter about how our team collaborated on developing our Product Strategy. I hope it will be helpful to those who need to do similar work in 2023. You can read Part 1 (and subscribe to get the rest) here

When shutting down a product is the right thing to do

In Google has a company strategy, not a product strategy Jackie Bavaro argues that instead of product strategies, Google has… this:

Google’s company strategy is “Hire all the smart people.” Hire all the smart people and let them build. Hire all the smart people so they can’t work at a competitor. Hire all the smart people even if we don’t have something important for them to work on.

She goes on to argue that this is the main reason so many of Google’s products get shut down:

I think the lack of a product strategy is behind many of Google’s short-lived products. Projects like Google Wave, Google Inbox, or Stadia get the go-ahead without a deep, structured, well-reviewed plan for how they’re going to succeed and why they’re important. Some smart, ambitious person at the company spear-heads the project and pushes it through to launch. When the product isn’t a runaway success, Google cuts its losses and moves on to the next thing.

If Google didn’t start with a conviction that they needed the product, it makes sense that they wouldn’t have the stamina to keep iterating and investing. Most other companies don’t have the money to build and launch products with such little conviction and oversight. Other companies need their products to succeed, so they try harder & smarter to make the products successful.

It’s a good post (that she accurately calls “spicy”!). I found it particularly interesting because how Jackie describes Google reminds me of one of the key principles we had at Wildbit:

Businesses are product agnostic. Products are an output of a team’s skills, strengths, beliefs, and values. Companies that define themselves by what they make automatically impose limits around what they can do.

We wanted to keep working together as a team, which meant we had to create products that people love and are willing to pay for, and that is what drove us. We were always worried about being defined only by our biggest product, so we kept experimenting with different things. Sometimes it worked—DMARC Digests is still going strong. And sometimes it didn’t—the team shut down Conveyor after the final pivot just didn’t work as well as we had hoped. But in the midst of it all, our #1 principle remained intact:

Businesses exist to serve people. As a tool, businesses exist to support human constituents: the Founders, the Team, the Customers, and the Community.

When we shut down Conveyor that team didn’t leave—they moved back into the larger team to work on our other products. So as I reflect on why the decision was made to shut down (or find a new home for) some of our products over the years, I’d like to believe that we didn’t do it because we didn’t have a product strategy—we understood our audience and the problems we were solving for them very well. We did it because when it comes down to it, all products are experiments until they’re not. And when we couldn’t get experiments to a place where they supported our founders, the team, the customers, and the community well—when the situation essentially violated our company principles—we had to face that reality and act on it.

I think that’s ok, by the way. When a team has the safety to know that they won’t lose their jobs if the product they’re working on isn’t ultimately succesful, they are able to more clearly see the world for how it is. They can acknowledge when a product isn’t on a path to success, and when it’s time to move on.

I miss Google Reader and Google Inbox too. But after working in a “product-agnostic” company for 6 years I have more empathy for teams who decide to shut down products that seem to have a big following. The issue is not necessarily that those teams don’t have clear product strategies. It’s that sometimes the gap between product strategy and product reality becomes too large, and keeping the product going would end up doing a disservice to the business, the team, and customers. Strong product leadership is seeing reality, acknowledging it, and keeping the team safe during the process of shifting to a new experiment or existing product.

Use “survival metrics” to determine the right project status

I like Adam Thomas’s idea of identifying “survival metrics” at the start of a project. It’s a way to help teams stay grounded throughout the project and ask themselves whether they should stop the project, pivot in a different direction, or continue to invest in completing the project. From What Are Survival Metrics & How Do They Work?:

Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.

Adam goes on to discuss three questions that help teams identify those survival metrics.

A framework to identify issues to unblock growth

Here’s a good analogy from Josephine Conneely to help figure out why growth might be stalling:

Imagine each of the 3 criteria pillars, Product, GTM and Org, as legs of a stool. Ideally each leg is of even height. This allows it to sturdily hold whatever is needed (in this case it’s increasing user volumes). Each leg can continue to grow (perhaps this is some sort of stool tree), and as long as the legs grow in tandem the success metrics of choice are safe. However, there may at times be an imbalance. Imagine an organisation with a great sales and marketing team who have created such demand that the product is struggling with performance issues as it scales to meet increased usage volumes. This leads to a lopsided stool, which while functioning, is not operating in manner which enables the org to capitalise on growth potential. If the product issues are not rectified, this could result in churn, reputational damage and a negative growth trajectory. Imbalance leads to lost opportunities.

Read the whole article for an illustration of the concept, and also how to use the framework in practice.

The nature of product

You can scale with process, or you can scale with leaders. The only way that leads to good outcomes is scaling with leaders.

— Marty Cagan, The nature of product on Lenny’s Podcast

Create awareness of reality through bottom-up strategy

Tim Casasola’s post Create awareness of reality through bottom-up strategy points to an issue that we often see in teams—the work that they are doing is disconnected from the company’s core strategy:

There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. “It’s great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment… and we’re far from where we want to be there.”

And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.

The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.

Tim points to John Cutler’s “Bet Up” activity as a useful exercise to make this disconnect clear:

This seems like a really useful exercise for teams to undertake. It might also be really interesting to ask the executive team to fill out row 4 of the above, and see how their answers differ from what the teams come up with. Exposing a big strategy mismatch in such a clear way could be a really powerful tool to move the organization in a direction where a team’s day-to-day work is reflected in the overall product strategy.

Leadership and product strategy lessons from Reid Hoffman

Ben Casnocha has a long, excellent piece entitled 10,000 Hours with Reid Hoffman: What I Learned, in which he shares a bunch of lessons he learned from then LinkedIn founder:

A lot of strategists (and CEOs) think that their job is to conceive a strategy and then hand it off to the underlings to execute. They might concede that delegation matters, but usually as a matter of execution more than strategy.

Reid disagrees. He once told me, “Whoever is actually immersed in the actual execution of a strategy should always think of ways to tweak the strategy for the better.” It’s a litmus test for talent: How do you know if you have A-players on your project team? You know it if they don’t just accept the strategy you hand them. They should suggest modifications to the plan based on their closeness to the details. And as they execute, they should continue to tweak the strategy, and you (the owner) should not feel a need to micromanage or second guess—if you do, you’ve got the wrong person.

The whole piece is full of wonderful gems like that. Highly recommended read.

Turn customers into a coalition of defenders

I love this sentiment from Rich Ziade in the post The New MVP: The Minimum Valuable Product. He talks about what happens when customers become a coalition that shares your mission. This is written from an agency perspective, but it applies just as much to product companies:

There is no more powerful political tool than releasing good software into people’s hands. You’ll find that the burden of consensus-building and campaigning is far lighter because the thing speaks for itself. It’s something you can draft behind to keep going.

Rinse and repeat. Done right and you’ll bank some political capital. You’ll need it along the way. Mistakes will be made and you will be blindsided by who-knows-what. Ideally you’ll string together a few wins that continuously impress people. Trust increases, anxiety decreases the temperature has gone down. What were once your customers will become part of your coalition, defending your product and mission because it is now their product and mission.

“…it is now their product and mission.” That is an excellent goal we can all aspire to.

Education as customer research for product development

I enjoyed this interview with Todd Curtis, Chief Product Officer at You Need a Budget. They cover a lot of ground in From spreadsheet to digital product: You Need a Budget’s Product Excellence evolution, but I especially like the discussion about the many different customer touchpoints they maintain:

As ideas move into discovery and validation, Todd and his team go to customers directly. Todd tries to have hour-long sessions with two customers every week to learn about their budgeting story. Through the company’s frequent online workshops, YNAB is able to engage with hundreds of customers each day and hear their questions and concerns.

All these efforts help YNAB gain a deep understanding of what their customers really need and informs product strategy with actionable intelligence.

The use of workshops (or in our case, webinars) to engage and get feedback from customers is a great practice. It provides tons of value to customers while also helping companies to understand their needs better.