Menu

Posts tagged “product management”

How your product is discovered and adopted is part of the product

Shift left on go-to-market to build better products is a great post by Frank Tisellano on why product managers have to consider Go to Market efforts while they are still deep in the understanding/planning phase of a project:

Great PMs recognize that building a good product is table stakes and that the way to truly differentiate themselves is by taking a strategic approach to how customers or users find and adopt their products.

In other words, great PMs shift left on go to market, considering and developing their distribution strategy while they’re still prioritizing problems to solve, long before a PRD is written, let alone a line of code.

He goes on to give some practical tips—and examples—on how to make GTM a bigger part of the PM process.

Taylor Swift, Fender Guitars, and Product Management walk into a bar

I recently came across two articles that combine the topics of music and product management. That is basically catnip for me, so I have to share.

First, I know “What X Can Teach Us About Y” articles have become a bit of a trope, but trust me on this one. What Taylor Swift Can Teach Us About Business by Rex Woodbury is an excellent case study on what good product management is all about. I’ve always been impressed by Taylor’s business strategy, and this is the first article I’ve seen that really digs into it. On Taylor’s decision not to sign with RCA because they wanted to pigeonhole her into being a country singer:

The key insight here is that RCA underestimated the market. Yes, country listenership was declining among young people. But great products revitalize stale markets and ultimately expand their markets. Swift did both, first proving that there was an opportunity in country music, and later growing beyond country to become a bona fide pop star. Swift’s story reminds me of a fatal error in startups: underestimating market size.

There’s too much goodness to quote here, so just read it.

The second one is an older piece that I found via Jeff Gothelf’s blog. It’s an interview with Fender CEO Andy Mooney on the company’s mission, and once again it showcases some excellent product management principles. In the example below, Andy talks about the creation of the Fender Play app. I am breaking the quote up with some of my notes, since it encapsulates the process so well:

The marketing is tied around creating the emotional connection, being ‘why should I do this?’.

Note the focus on Jobs to be Done. Their research showed that people pick up the guitar mostly because they want to play and sing along to their favorite songs—not because they want to be rock stars. That’s the emotional connection they are going after.

Again, with Play, we felt that it was a milestone to get people to commit if they were able to master their first song. So we teach the skills that you need in Play around doing exactly that. You come into the product, you declare your genre and that gives you a potential setlist.

Note here how they identified their activation metric / a-ha moment and built the product around getting users to that moment as quickly as possible.

Then you get taught the skills to master those songs rather than the other way round. I taught when I was very much younger. You know, are you going to teach somebody to play major minor scales or are you going to teach them how to play House Of The Rising Sun? My approach—which I’m glad was all intuitive back then—was a song-based approach because you were teaching them how to play the chords within the context of the song.

Again, note how they focus on the how music makes you feel, not on the theory behind it. We are all used to this kind of marketing now but it’s worth remembering that until the iPhone came along, phone marketing was all focused on storage space and RAM, not on here’s what you can do with it.

There’s much more in the article about the extensive customer research that Fender did, and how they used those insights to create Fender Play.

Authentic leadership is about getting in the trenches with our teams

Here’s an interesting take by Sheril Mathews on why people often don’t trust their managers, or find them inauthentic:

Managers don’t come across as authentic because more often than not they don’t have an intimate understanding of the day to day realities of how their teams actually get work done.

Sheril goes on to discuss some some great advice on how to show up for our teams in authentic ways (spoiler: it’s about getting our hands dirty in the trenches). But I also wanted to share this 1973 (!!!) quote from Henry Mintzberg in The Nature of Managerial Work, because it really stopped me in my tracks:

The prime occupational hazard of the manager is superficiality. Because of the open-ended nature of the job and because of the responsibility for information processing and strategy-making, the manager is induced to take on a heavy load of work, and to do much of it superficially.

Hence the job of managing does not develop reflective planners; rather it breeds adaptive information manipulators who prefer a stimulus-response milieu.

Sheril’s article—and that quote—is inspiring me to take a real hard look at my own work, and where there could be opportunities to weed out the “superficiality”.


This is a bit of an addendum that I think is valuable enough to add here. I shared the above Mintzberg quote among some friends and the discussion ended up being really interesting. Vince pointed out that as for the assertion that superficiality is an inevitable outcome of management, he prefers Russell Ackoff’s take from 6 years later. Here’s what he said in 1979:

Managers are not confronted with problems that are independent of each other, but with dynamic situations that consists of complex systems of changing problems that interact with each other. I call such situations messes. Problems are abstractions extracted from messes by analysis; they are to messes as atoms are to tables and charts … Managers do not solve problems, they manage messes.

Pete (who I’ve been begging to start a blog, please go yell at him as well) also went the less cynical route with his comments:

As you move up the levels of a company, you move to higher levels of abstraction. Every level takes the output of the level below, and distills and summarises it, passing it up. It also takes direction from above and tries to nudge the processes below in that direction.

I think that’s the just way it is, the way it has to be. I can’t think of any examples where a different model has been applied successfully at scale.

The key to this working successfully though is to make sure that information is correctly analysed, distilled, summarised and communicated at every level.

The problem with superficiality is not abstraction. It’s dillution. If you throw away the good parts and keep the wrong parts when summarising, the system starts fraying. And you’re setting those above you up for making the wrong decisions, and thus setting up those below you for failure.

How to help our managers work with us more effectively

I’m sure we’ve all seen those “here’s how to work with me” documents (and the controversies around them), but I like this slightly different take. In her post 9 Managers in 4 Years: Creating Continuity in Chaos Genevieve Conley Gambill shares a framework for helping our managers understand our skills, our work, and our career goals:

  • Foundation – What are my unique strengths and capabilities?
  • Trajectory – How do I view my current role and performance?
  • Aspirations – What am I working towards in the future? 
  • Support – What do I need to adjust or build on to get there?

She also shares a great Google Doc template with more details. The post goes into more detail on each section of the framework.

How to Be a PM That Engineers Don’t Hate

From How to Be a PM That Engineers Don’t Hate:

You see it everywhere: Engineers complaining about the product managers that they work with. Hating on PMs is kind of like complaining about your utility provider or the TSA—so universal that it’s always good for a light chuckle in the right circles. The PMs don’t know how the technology works. All they do is send emails and take credit. They’re meeting generation machines.

When I interview engineers my first question is always, “Tell me about your experience working with PMs.” I do it to calibrate what kind of PMs they are used to working with, or to put it another way, how much I should apologize for our profession before we continue…

Anyway, the linked post is less about that, and more about some things PMs can do to work more collaboratively with other teams—not just engineering. Lots of good, practical tips and examples here.

Using “steel threads” to reduce product delivery risk

Jade Rubick resurrects an old engineering concept (and dead Wikipedia page!) in Steel threads are a technique that will make you a better engineer:

A steel thread is a very thin slice of functionality that threads through a software system. They are called a “thread” because they weave through the various parts of the software system and implement an important use case. They are called “steel” because the thread becomes a solid foundation for later improvements.

With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.

He explains this in detail in the full post, with lots of helpful examples.

Product team principles for focusing on short-term growth

We’re shipping rafts this year, not boats is a sobering read from Nate Jones that covers 8 principles for product teams who had to make a shift to short-term growth projects in 2023. An example:

It’s long-term if it’s short-term. That’s two principles for the price of one. First, realize that building to keep the business going today is long-term. That can help product teams recognize they have a long-term role to play. Second, any product plays with long-term payoff have to also include short-term revenue potential. You need both-and this year to innovate.

You might not agree with everything he says in this post, but at the very least it will get you thinking about your own team’s principles and priorities as we continue to navigate this… “complicated” year.

The 4-subfunctions of growth marketing, and a good Figma example

In How to organize your B2B growth marketing team Emily Kramer explains growth marketing in a way that I think I finally understand:

To support full-funnel marketing, multiple GTM motions, and all of the data and tools available, 4 sub-functions of growth-marketing are needed: Demand Gen, Inbound & Web, Lifecycle Marketing, and Ops & Analytics.

Emily also touches on the many ways that this team ideally works with Product and Engineering. It’s a highly recommended overview of this critical function in an organization.

And speaking of growth marketing… In Figma and product-led sales Jesus Requena, former head of growth marketing at Figma, shares some really interesting details on how Figma’s Growth team works with their Sales team:

We wanted to take this to the next level and learn what exact product behavior correlated with an upgrade. We partnered with our data product team, sales ops and sales leaders and created a model that surfaced around 10 data points. When two or more of these were triggered, there was a high likelihood for the account to upgrade. We showed sales and sales leaders the data and got their interest, then we tested it in a small group. Endgame, the product-led sales software, helped us display the data at account level and user-within-account level.

Meaningful metrics: How data sharpened the focus of product teams

In Meaningful metrics: How data sharpened the focus of product teams Erin Gustafson goes into detail on how Duolingo grew their Daily Active Users (DAUs) by 4x since 2019. It all starts with the growth model they built:

The Growth Model is a series of metrics we developed to jump-start our growth strategy with data. It is a Markov Model that breaks down topline metrics (like DAU) into smaller user segments that are still meaningful to our business. To do this, we classify all Duolingo learners (past or present) into an activity state each day, and monitor rates of transition between states.

Once they were confident in the model they did a bunch of simulations to build a hypothesis of where they should focus on for the most growth:

With the Growth Model in place and trained on historical data, we began to run growth simulations. The goal of these simulations was to identify new metrics that—when optimized—were likely to increase DAU. We did this by systematically pulling each lever in the model to see what the downstream impact on DAU would be.

Click through to see a visualization of the model, and where they are planning to take this work next. The article also pairs well with Jorge Mazal’s How Duolingo reignited user growth.

Don’t give up on the value of product management because of bad past experiences

Maybe 10 years ago I would’ve gotten upset about an article like Spencer Fry’s No PM, no problem: how we ship great products fast, in which he explains why they don’t have product managers at Podia and how great that is. Luckily I’m now too old to stay up late just because I think someone’s wrong on the internet. Instead, I approach articles like these—ones I viscerally disagree with right off the bat—with a bit more curiosity. What is the source of the author’s assumptions? What is the data that led them to this particular set of conclusions? What is the problem they’re trying to solve, and what led them to this viewpoint as the solution?

As it turns out, we get the answers to those questions pretty early on in Fry’s post:

Why shouldn’t the developers—or designers—be tasked to work through the problems, instead of being handed a set of solutions?

Every single project, a developer is assigned what we call a Champion role and it’s that person’s responsibility to act as the PM in addition to their work as an individual contributor. This approach, as opposed to handing off a spec to stitch together with code, makes for much more engaged developers who feel more ownership of the work.

Ah, see, this makes sense! I can see why Fry concluded that PMs are unnecessary if his experience is that they (1) “hand off a spec to stitch together with code”, and (2) don’t give developers ownership over their work. The problem is likely that he has never worked with a PM that understands their role and does it well, so of course the data would lead to the conclusion “no PM, no problem”.

So let’s talk about those two assumptions for a minute.

Handing off specs to developers

This is just 100% not what PMs should do. If designers, developers, QA, marketing, and customer success are not part of the planning and design process of a feature, it’s just bad practice. There should never be a handoff in software development, only collaboration. A developer should know exactly what they’re doing once they start coding because they have been intimately involved in the design decisions and trade-offs that go into a project right from the start.

The role of the PM during this phase is to bring all the right customer and business data to the table to help the team through their decision-making. It is rare for them to say “this is the decision,” but in some cases where teams can’t come to an agreement it’s also their responsibility to make that call, explain it well—and be accountable if it ends up being the wrong decision.

Ownership of work

Engaged team members (not just developers) who feel ownership over their work is an essential element of an empowered team. If the teams don’t have that and the PM “calls the shots” then that is, again, bad product management.

At Postmark we have a similar role to the Champion role Fry uses at Podia. We call it the Driver (part of the DACI model). The PM is sometimes the Driver on a project, but not always. In every case where it makes more sense (such as a deeply technical back-end improvement, or a pure front-end redesign) a developer or designer or marketer is the Driver. We define the role as follows:

The Driver is the project leader. This is the one person who will be driving the team through decisions. They’ll be responsible for making sure all stakeholders are aware of what’s happening, gathering information, getting questions answered, and action items completed. A Driver, for example, will schedule and run project meetings, gather and distribute ideas, coordinate tasks, and track the team’s progress.

Drivers ensure a decision is made but don’t necessarily make the decision.

The team has autonomy and ownership to drive the project and make decisions as they see fit. Each project has an Approver assigned, usually someone on the leadership team, but they are there to support, answer questions, provide context, and in rare occasions, help make a decision if the team is at an impasse. PMs shouldn’t “own” projects. Teams should own projects.

So what do PMs do, then?

Fry’s post does allude to an age-old question, though: Why do you need separate PMs? Why can’t someone on the implementation team just do it? The short answer is that what goes into good product development and successful features is so much broader than just the code being written and shipped. And if we require designers or developers to be responsible for all of it, they would simply never ship anything.

So what value should PMs bring to the team, whether or not they are the Driver/Champion on a project? In addition to input on design/scoping decisions they should be responsible for all the things that are not directly related to building the feature at hand, but essential for its success. Some possible examples:

  • Customer input on what their needs are to help with the design and scoping of the feature.
  • Revenue modeling to figure out pricing and packaging.
  • ToS updates due to legal implications no one else thought of.
  • Working with the marketing team to figure out the best positioning and launch activities based on what value customers can expect.
  • Connecting the dots between this project and that failed one from 3 years ago as well as that thing the Lead Architect said in a meeting last month to ensure we don’t forget about an essential library dependency so that we actually build something that’s scalable and reusable in the future.

You get the picture.

There is enormous power in someone being around for the team as the person who’s got this so that they can focus on their work and relax in the knowledge that nothing will fall through the cracks. More than any other role in the organization, it is good product management that enables teams to work in a calm, empowered environment that produces consistently great software.

I have no doubt that Podia ships great products fast. They clearly have a culture of trust and empowerment, which is great. I do wonder how adding a good PM to the mix would enable them to go to even greater heights.