Ideas

Inspired by "Today I Learned" blogs, these are ideas that seemed worth writing down.

Why are product managers unhappy?

Trigger warning: this post has nothing to do with AI.

Wait, are PMs unhappy?

I’ve been talking to a lot of people in tech, including many PMs. Not all, but many of them spoke about managing frustration at work. To see if my suspicion was part of a larger trend, I turned to the /r/ProductManagement subreddit. I scraped every post and ran a simple sentiment analysis.

Nothing particularly jumps out. Note that the subreddit was much smaller when it started, so naturally there was more variance early on. According to this analysis, the overall sentiment isn’t particularly negative. As a baseline, another subreddit I follow, /r/modular, averages a very similar 52% positive words in the last three months (source).

However, my analysis using the Bing lexicon doesn’t capture the true sentiment of /r/ProductManagement. One of the popular “positive” words was “hug.” Searching the subreddit for “hug” turns up some pretty eye opening posts:

“I am giving up on my career”
“I feel like I’m under attack”
“PM team needs some love”
“Unfair performance management”

Not particularly uplifting stuff. One user said they left a career in product management to take a quarter of their old salary to become a high school teacher. Something is going on here.

How to be a terrible PM

The most upvoted post in the ten year history of this subreddit, by a landslide, is My Advice on How to Be a Terrible but Valuable PM. Key excerpts:

One of the cruelest lessons I’ve learned as a PM is that success comes in two forms, and they rarely align:

Being a Good PM – Driving meaningful impact on the business and its KPIs.

Being a Valuable PM – Ensuring leadership sees you as valuable.

In an ideal world, focusing on #1 should be enough. But in reality, #2 often determines your career trajectory and job stability, regardless of actual impact…

…I'm no longer losing my sanity trying to make a product successful or trying to single-handedly build a productive product culture. I've got an amazing work-life balance.

Professionally, I'm completely dead inside.

— u/token_friend

Marty Cagan, the pre-eminent product thought leader, has written and spoken extensively about what he describes as “product theater.” He’s describing this.

People who have been frustrated working with PMs—they’re describing this.

This is someone who knows how to do their job, who knows how to help their team succeed—but they can’t win the hearts and minds of leadership, and it’s not in their best interest to try. So instead they become an overpaid project manager and focus on gaming the optics.

There’s an ongoing debate in the comments if this post is satire. I don’t think it is. And even so, satire is always grounded in a truth.

That this post received more than 2x the upvotes versus any other post (source) tells me they’ve hit on something universal for this community of PMs.

Rewind: the three phases of becoming a great PM

Tons of people have jobs that aren’t all that fulfilling. It shouldn’t be a groundbreaking insight to say that playing internal politics helps you succeed in corporate America. Why did this post generate such a response? To understand why PMs are so frustrated, consider how PMs’ careers progress as they become more senior. Every product manager’s career evolves through three phases:

Phase One

The first phase is learning to do the job well. This is all about the nuances of applying design thinking principles in practice, applying the right prioritization framework to the right problem, identifying and keeping customer problems front-and-center, getting good at user research, getting good at project management, getting good at effective communication—there’s a laundry list of skills PMs need.

At some point, the Phase One PM becomes the leader of a successful team. They are doing good work, but there is one big problem: everything flows through the PM. They are a bottleneck for approving designs, making engineering decisions, GTM comms, triaging customer support bugs, and more. A Phase One PM will complain, “I never have time to do strategic work!” “I am in meetings all day!” They are in a vicious cycle, stuck in the weeds and low level details. Enter Phase Two.

Phase Two

Now that the PM is fairly skilled, Phase Two is all about upleveling their team. The Phase Two PM is a coach; after all, the best way to prove you understand all your Phase One skills is to teach them to your team. Phase Two PMs push their designers on UX principles. They shift the engineering culture on their team to become product-minded. They empower everyone in their orbit with shared decision frameworks. They drive a customer-obsessed culture. They teach their team to care about outcomes over outputs.

Culture changes take time, but eventually, they build trust and autonomy. The team is really humming, and the PM is no longer a bottleneck or feeling stuck in the weeds. Now they can focus more of their effort on things only they can do (typically, product strategy).

But now, they realize the biggest bottleneck to their team’s success isn’t coming from within the team…

Phase Three

If you’ve ever had a job, you’ve been frustrated by your boss at some point: An executive who simply wants their idea in the product, ASAP. A leader who can’t make up their mind and pivots so drastically and rapidly, nothing can get done. Misalignment on the cost of quality leading to teams only ever shipping MVPs. Teams being evaluated on “velocity” above all else (”feature factories”).

These scenarios are unavoidable; working with fellow humans is like herding cats. If Phase Two is about managing down the org chart, Phase Three is when PMs need to manage up. Exceptional PMs carve out space for their teams to do incredible work, even if the organization at large is inadvertently hostile to building great software.

(Important note: there is not one way to build great software, but there are a thousand ways to build terrible software.)

Every company is dysfunctional, each in their own way. A PM’s real job is to find the dysfunction, insert themselves directly into it, and slowly correct course. It is an unwritten job description. But this is the primary role of a Phase Three PM.

To be a great PM, it isn’t enough to be able to do the job, you have to be able to empower your team to make product decisions. But that isn’t enough either: you also have to manage up to empower your org to make good product decisions, all the while still executing at a detailed level.

PMs are stuck

The “Terrible but valuable” post tells me PMs are struggling to move from managing down (Phase Two) to managing up (Phase Three).

…PM is turning to shit. I’m trying to pivot into a different career after 8 years because leadership is too abstracted away to tell whether ideas are good or bad and would rather take in the snake oil.

— /u/evergreen39

Too many people in our industry view themselves as a victim of their company, like they're stuck in a feature team and there's nothing they can do about it other than quit.

—Marty Cagan

I see four converging factors affecting PMs today:

What is your job? Job expectations vs reality can lead to sustained frustration.
Managing up is a skill gap. Many PMs don’t have experience managing up.
Bottoms-up change is hard. As an individual contributor, your power is limited.
The struggle is universal. Because of market dynamics, Many PMs are experiencing this painful realization all at once.

What is your job?

Anytime there is consistent tension or misalignment at work, I’ve always found it has to do with mismatched expectations of job responsibilities. If you’re a frustrated PM, there’s a good chance you think your job is defined by what was on the offer letter you signed, something about "developing and executing a comprehensive strategy” or “building a deep understanding of the needs of users,” but you’d be wrong. Your actual job is probably about managing up, slowly winning hearts and minds on the path towards Marty Cagan’s “product operating model.”

Senior PMs know how to do great product work. They also know when the product org at large is shooting itself in the foot. Super senior / Principle / Staff PMs know how to do something about it.

Managing up is a skill gap

I love tech, I love solving hard problems, but I hate the politics.

— Lou, Product Consultant

Managing up is based on strengthening relationships and building trust. For many PMs, there’s a skills gap: the managing-up skills that make someone a great Phase Three PM are skills that they likely didn’t need much in Phase One or Phase Two.

Many leaders I’ve worked with are inherently distrustful of product managers. They’ve worked with bad ones who seem to only stand in the way between engineers and customers. As a PM, execution is your core currency with leadership. If you’re team isn’t executing, and you blame leadership, you’ve earned no trust and you’ve created a dead end for yourself. And if your leader has already been burned by underperforming PMs in the past, you’re starting with a disadvantage.

As remote work became more popular, building strong working relationships became harder. Knowing someone beyond a Zoom meeting is key to being able to have hard conversations, and making hard conversations feel easy is critical to managing up effectively.

Bottoms up change is hard

Marty’s latest book, Transformed, is explicitly geared towards educating leaders on how to adopt the “product operating model”—aka empowering teams to build great software products. He knows leaders are the bottleneck; it’s why he chose to write the book. In it’s entire 435 pages, there is only a single page on what you can do as a IC PM. Marty is saying the important part quietly: As an individual contributor, there isn’t much you can do.

To be explicit: The CEO needs to be viewed as the chief evangelist for the product model [transformation]. If this is something your CEO is unwilling or unable to do, then you can likely save yourself a lot of time, money, and effort by reassessing your readiness [for the product operating model]… While theoretically not impossible, it is extremely difficult to transform successfully without the active support of the CEO.

— Marty Cagan (from Transformed)

In Marty’s view, IC PMs need to hone their craft. The whole thing falls apart if IC PMs aren’t able to execute at a high level. The weight of the transformation—and managing up—falls on product leaders. Unfortunately, product leaders are also susceptible to the grift of becoming seen as “valuable” over all else. So as a IC PM, you’ve got a long road ahead of you.

The struggle is universal

And because of the dynamics of the industry at large, there’s a whole cohort of PMs who are realizing this all at once.

Congratulations, you’ve fully unlocked PM Enlightenment™—the moment when you realize that career success has little to do with actual impact and everything to do with optics. You’ve cracked the code, my friend.

— /u/phil42ip

In the workforce today, more PMs are more senior than ever. I’ve been having a lot of conversations with folks across the tech industry. One of the trends: no one is hiring junior PMs. In fact, some companies were so burned on “product theater” they are adverse to hiring PMs at all (like Posthog).

We are now in the post-ZIRP (zero interest rate phenomenon) world. When money was cheap, growth was easy, and the pandemic was fueling digital engagement, there was a huge influx of hiring. Now there is a generation of tech workers who have been scarred by working with terrible product managers. I’m sure you’ve worked with someone who had a senior title but wasn’t operating as a Phase Three (or even Phase Two) PM. As a correction, a higher percentage of PMs in the workforce today are more senior than in the past.

Additionally, product management as a discipline has been around for long enough that it’s matured. More people than ever know how to do the job really well. There’s a whole ecosystem of PM influencers. Marty Cagan has been writing about building great software products at SVPG for 23 years.

Conclusion

Why are PMs so unhappy? In essence, because they lack agency.

They are senior enough to know there’s a better way to innovate…
But they don’t have the skills to change their leaders’ behavior to fix the problem…
Managing up isn’t the job they thought they signed up for…
And in many cases, even if they try, they can’t fix the problem…
And because of market dynamics, many PMs are all experiencing this realization at once.

What’s next? I don’t think it’s all doom and gloom. AI will force many companies to truly innovate, especially after the initial VC money grab winds down. That should push leaders to be more open to change. If Marty is successful, more CEOs and leaders will have heard of the product operating model. And in the meantime, more PMs should hone their skills at managing up (I’ll dig into strategies in a future post).

Anti-disciplinary thinking

I love solving hard problems. I love thinking about how to solve hard problems: why processes work or fail, why design thinking is so powerful. One thing I truly believe is that to solve really hard problems, you have draw from a variety of backgrounds and disciplines. An extreme example: there’s an old story of a computer scientist getting brunch at a dim sum restaurant and inventing a more efficient network optimization algorithm after seeing the ladies push their carts through the restaurant. Solving hard problems means expanding your world, finding things you didn’t know you didn’t know.

Growth mindset underpins a lot of the most effective problem solving frameworks. Being curious as a default first step is critical to coming up with new ideas. I wrote about it here: What is ‘growth thinking’ part I (and by the way, being curious-by-default is also really important for socializing, from having healthy relationships to meeting strangers).

Zero-sum thinking can be dangerous for innovation, but it’s very common to think about the world as a series of zero-sum games. Case in point: game theory is based on an assumption of diametrically opposed parties. But in design, there really are solutions that exist where everyone can win. In a lot of ways, finding those solutions is the job of being a designer.

The way to find those win-win ideas is to break out of your current silo of thought, whatever it may be. It’s hard to recognize your own biases or thought silos; this is (one of the many reasons) why having diverse teams matter. Steve Jobs talks about the most exciting work living at the boundary of multiple domains, not just at the center of a single domain. MIT’s Media Lab takes it farther: it’s not just about combining two or more disciplines (_inter_discplinary), it’s creating something entirely new, something that is more than the sum of it’s parts (_anti_disciplinary). It’s the principle behind the teams that first 3D printed glass, or invented the first touchscreen, or made Guitar Hero, or designed fabrics made out of living organisms.

Lin Wells (quoted in Thomas L. Friedman’s Thank You for Being Late) puts it beautifully:

“It is fanciful to suppose that you can opine about or explain this world by clinging to the inside or outside of any one rigid explanatory box or any single disciplinary silo… [there are] three ways of thinking about a problem: “inside the box,” “outside the box,” and “where there is no box.”

Say vs do

In a user interview, anywhere a user says one thing but proceeds to do another, that’s a golden nugget of insight.

What does AI art say about us?

The world is a drop of dew.

A drop of dew it is indeed.

And yet, and yet…

— Kobayashi Issa, 1819

This is my favorite Haiku (roughly translated from Japanese). It might be the only Haiku that I have memorized. I think it’s beautiful, from the moment I first heard it over a decade ago.

Snail climbs the mountain—

one blade of grass at a time,

no need to hurry.

— ChatGPT 4o, 2025

ChatGPT can also write haiku. It wrote this particular haiku because I asked it to. Issa wrote “drop of dew” because his one-year-old daughter died.

The meaning, the significance, the emotion of his poem doesn’t exist on the page, in between the words. The meaning exists out in the world, in the emotion felt by Issa and everyone who’s read it in the 200 years since. If you didn’t know the poem, what did you think about it before I told you about why it exists? How do you feel now that you know?

With AI art, the question is always ‘why does this exist?’ It doesn’t exist to bring its AI creator joy (or any other feeling). Like any art form, if it inspires emotion—even negative emotions—it’s probably good art. Movies you hate with a passion because they got you feeling some type of way may or may not be fun movies, but they are probably good art.

I saw an AI-generated image of the cast of Harry Potter in the gym, absurdly buffed out a la Schwarzenegger in Pumping Iron. That’s a bizarre but fascinating piece of art. It stirred up some confusing and complex emotions in me. But it didn’t stir up any emotion in its creator, because AI doesn’t have emotion.

source: @tunguz

Maybe you could argue the creator was still the human who prompted it, and the AI was simply the tool. That’s a fair point.

My wife has a little pencil bag that says “MAKE BAD ART.” Everyone should make bad art. Because the point of art isn’t only when it’s “done”, the point isn’t only that it exists; the meaning is in the making. If you told me some dude spent 1,000 hours painstakingly shading each vein in Daniel Radcliffe’s bodacious forearms, that’s something. If you told me some dude spent 2.3 seconds typing out “Cast of Harry Potter as bodybuilders”, that’s something else completely. The meaning isn’t completely encapsulated in the artifact itself. You can’t separate the thing from the making.

A popular genre of social media posts is “The Great Transformation”: the before and after of a glow-up, a haircut, a home renovation. This genre glorifies the final outcome. As the viewer, we skip over everything that happened in the middle and cut straight to the end, which feeds our tiny attention spans more dopamine. AI art is symptomatic of this societal ill.

Eckhart Tolle, author of The Power of Now, talks about collective presence. Being present isn’t just something each of us can do to find inner peace. It’s something you can see on a macro scale. Just turn on the news—we are not very present. In fact, we seem to be pretty angry. To make AI art, you don’t have to be present for the journey. In a few keystrokes, you can skip to the end.

Using technology well means asking good questions. At the birth of social media, Facebook marketed itself as helping you “connect” with your friends. But what does it really mean to have a connection with someone? I think we can universally agree that the experience we get on social media is pretty different from feeling deeply connected with another human.

Maybe this is a call to action: feel things deeply, even if they’re not always pleasant. Make bad art. Appreciate the journey. Be present. Ask good questions. Hit the gym like Harry Potter.

The more product management changes, the more it remains the same

The more things change, the more they stay the same.

Building AI products makes product fundamentals more important than ever: because LLMs are non-deterministic, iterating faster and derisking early in the build cycle is critically important. The same principles that distinguished high performing product teams in the pre-AI era remain today.

As a PM, should you be staying up on the latest technology developments to apply new approaches in your work? Absolutely! AI hasn’t changed that. If anything, it’s made following the tech more important.

As a PM you need to communicate complex ideas concisely and clearly. Can you write more concisely and more clearly with an AI cowriter? Probably! But the need remains the same.

Clair Vo’s three requirements of AI powered product management also fit nicely into this narrative:

“Automate yourself to speed up delivery” → In any world, becoming a bottleneck as a PM is a bad situation.
“Add new skills and do more” → Product management is an interdisciplinary field. Being a great PM always requires us to have technical skills AND design skills AND business acumen AND communication skills. AI makes it faster to learn, but the importance of diverse skills remains the same.
“Multiply your impact by teaching your team” → The biggest differentiator between junior and senior PMs is their ability to enable and empower their teams. Feeling stuck in the weeds, like you never have enough time for strategy work? Chances are, there’s an opportunity to coach your team to become more autonomous.

AI is absolutely revolutionizing the tech industry (and the world). But being a principled PM is still as important as ever.

Parkinson’s Law

“Work complicates to fill the available time”

— Cyril Northcote Parkinson

Amara’s Law

“We tend to overestimate the effect of a technology in the short run, and underestimate the effect in the long run.”

—Roy Amara

Product management is a balancing act

As a PM, you’re constantly finding tradeoffs. How do we balance value creation with value extraction? Short-term goals versus long-term goals? There are so many of these types of questions. In product management, balance is everything. To find balance, it takes focus, presence, and practice.

Balance requires awareness of what is on either side of the scale. I find myself constantly asking questions like “On the spectrum from X to Y, where do we want to be?” For example, imagine you are building a new feature. One of the balances you might want to strike is the eternal “MVP” debate:

But so often dichotomies don’t exist; you are never really only balancing just one thing, and it often isn’t the case that you must choose one at the expense of the other. For example, if we are trying to balance business needs vs user needs, maybe a spectrum is the wrong mental model to use (a lot of people use a Venn diagram for this). Ideally, we want to create opportunities that are good for users and good for the business. If we add a second dimension, our “spectrums” becomes chords on a circle:

Each of the balances you try to strike as a PM doesn’t happen in isolation—they interact with each other. Add a third dimension, and now instead of a 1-dimensional spectrum, we’re thinking about balance as coordinates on a sphere:

The final complication I can even imagine visualizing here is a fourth dimension: these balances don’t only interact with each other, they evolve and change over time. Business needs and user needs are constantly evolving, after all. Now, instead of visualizing “balance” as coordinates on a sphere, we are also considering how those balances change over time:

Balance is important. Recognizing what you are balancing is important. And in my opinion, a linear spectrum doesn’t always paint a complete picture when trying to describe what you are balancing.

The commodification of attention

Commodification can only occur in a marketplace that has already been standardized and abstracted. Tim Hwang, who formerly worked on public policy at Google, explains this using the example of Chicago grain markets: at first, farmers traveled to the market and sold their grain in person. With the rise of railroads, more grain was coming into the city’s markets than merchants could haggle over with each individual farmer. Additionally, there may have been many farmers all contributing grain that ended up on a single car on the train, at which point it was impossible to tell which farmer the grain belonged to.

To solve this problem, the grain markets took the first step towards commodification: standardization. The Chicago Board of Trade developed specific metrics to grade each category of grain. Merchants no longer needed to know the farmer that the grain came from; the system of standards assured the level of quality.

The next step toward commodification is abstraction. Now that merchants only needed to know the grade and quantity of the grain they are buying, there was no interaction with the farmers. Merchants who may not have any expertise about grain could now buy and sell quantities of grain effectively. The receipts for the quantity and grade of grain were the things being bought and sold, not the grain itself. Grain was now a commodity because the market had been standardized and then abstracted.

Tim Hwang argues the same process has happened in the marketplace for attention. The Interactive Advertising Bureau has created standards for internet advertisements much like much like the Chicago Board of Trade had standardized grain quality. Although attention is certainly less concrete than train cars of grain, the internet has provided the data and tools to measure the amount of interaction and attention each ad receives. As the technology matured, the marketplaces for buying and selling online advertisements have become more abstract. Ads are surfaced on the internet algorithmically and buyers are far removed from the users consuming the ads and often the individual products or sites where the ads appear. Your attention is a commodity.

From Subprime Attention Crisis

Impact and effort

For a given project, we often assume that there is a linear relationship between the amount of effort (or time) we put in and the amount of impact we get out. “The more time we spend on this feature, the more impactful it will be,” we might tell ourselves.

But this is rarely—if ever— the case. Many projects follow the Pareto principle: 80% of the impact comes from 20% of the effort. This is often the case in the earlier stages of product maturity: just having a feature is the most impactful thing you can do; polishing and tuning that feature will only have small incremental effects.

But there is another case: the inverse Pareto principle, where there is an exponential relationship between impact and effort. Some examples where this can happen are:

When an initial feature simply doesn’t work on its own because it is meant to work in concert with other, not yet developed features;
When you’re in an all-or-nothing situation. One of these all-or-nothing scenarios is fixing data quality issues: there is no value in your data analytics ecosystem if the data is only accurate some of the time.

If you are exclusively focused on speed, projects that have this type of curve can be dangerous. If you only build features that are easy to implement, you might be skipping the most impactful work.

Thinking about these curves is also important when scoping a project. You certainly don’t want to end up building an MVP that simply isn’t impactful.

Speed vs velocity

How do you measure your success as a product manager? In my experience, “speed” is one of the most common ways—in fact, someone I know was fired for being “too slow to ship.” Yes, you can’t create value if you don’t ship anything, but more often than not, speed isn’t the issue. In fact, evaluating PMs for how “fast” their team moves can have pretty negative side effects.

Instead of speed, we should think about velocity. Velocity has speed and direction. “How fast are we moving _in a certain direction?” _is a much better way to evaluate the pace of a product team. Moving fast with no direction won’t result in success. Most products don’t fail because they didn’t move fast enough; they fail because they built the wrong thing.

“If you go speedily in the wrong direction, you will end up in the wrong place.”

In the plot above, each of the vectors represents a project or feature. The magnitude of the vectors could be considered “speed”: it is how quickly / how much progress was made towards that particular feature’s goals and KPIs. Even though the plot on the right has smaller magnitudes (i.e. less “speed”), the net effect is much closer to the goal. Direction matters. It shouldn’t be surprising that shipping features willy-nilly without a clear product direction won’t result in success, but even so, it seems pretty common for teams to obsess about speed.

I joined a team that had almost exclusively focused on speed. Before I joined, they tried a lot of different things in a short period of time and they were able to launch new features at a record setting pace. But it was not clear why their product existed. There was no vision for where the product was headed, there wasn’t suitable analytics in place, the deployment CI/CD pipeline was a mess, there were A/B tests left running in various states… There were some big changes we needed to make to make sure we could provide value to our customers and our business. But when the team was lauded for their speed and encouraged to “move faster”, there was no incentive to slow down and focus on the things that mattered most.

From @shreyas

The value of process

Whatever outcome you are after, a good process makes it repeatable, scalable, and more likely. Processes work in two directions: good processes can make good outcomes more likely and bad outcomes less likely. For example, a good process for product development involves systematically evaluating the impact of your product on your target market, making it more likely your new features / products will be successful. A good process for deploying code involves unit testing and end-to-end testing to make it less likely you’ll release bugs.

When something bad does happen, it is often more important to look at what in the process allowed that thing to happen rather than just investigating what bad thing happened. For example, recently my team shipped some code that caused a crash. The particular mistake was identified, but we also identified a flaw in our testing process. We’re now more likely to ship crash-free code because of the additional focus on process. We didn’t fix a bug, we made it more likely bugs won’t be shipped in the future. That’s the power of process: making desired outcomes more repeatable.

I am a strong believer in strong processes, but how much is too much? It’s easy to over-engineer processes that ultimately slow the team down. Two useful tools for finding balance are 1. the rule of threes (if something happens three times, it’s worth spending more time on improving relevant processes) and 2. considering the cost of quality.

Carcinisation

Crustaceans will always evolve into crabs. They’re all on their evolutionary journey to their final form: crabs. There’s a weird corner of the internet that is really into this topic right now.

From Wikipedia

The product death cycle

This is a scary and powerful way to describe a product development pattern that I’ve seen first hand. There’s a lot of different scenarios to illustrate this concept—Shreyas Doshi outlines a good one here—but this is one recent example I’ve heard:

We have an idea for a feature—or sometimes the executive team has an idea for a feature.
We do some user research. We propose our solution to a few clients. We show them the shiny new prototypes. They like them.
We report back to the executive team: “Users like the feature!”
The feature is greenlit and implementation begins.
The feature launches. It is rarely used and has little effect.
We’ve come this far and we still think the feature could work, so we restart the whole cycle and do more iterations on the feature. Time goes by and we have accomplished nothing.

This is what the cycle looks like:

If you zoom in on the lifecycle of a single feature, here is what the cycle looks like. The X axis is time and the Y axis is whichever KPI was chosen for the particular feature:

This is closely related to the speed vs velocity concept: often, the most dangerous thing a product team can do is head in the wrong direction or build the wrong thing.

Some red flags that could be early indicators you’re heading toward (or already in) the death cycle:

Your company starts having a larger and larger focus on “go to market”—even within the product org.
There is a high emphasis placed on features. People talk about the business in terms of features, not problems. Everyone is highly solution-oriented, not problem-oriented.
The people selling the product don’t feel confident that new features are going to help them.

The product death cycle is insidious: it takes a long time for the symptoms to manifest, which means it is difficult and slow to diagnose.

If you think you’re in it, how do you get out of the product death cycle? A big part is being aware of your own biases. If you can carefully distinguish things that you assume from things that you know, you are a lot less likely to fall into the product death cycle.

Part of this means walking the walk of user centric design, not just talking the talk. Deeply understanding a user need is a lot different than determining if a user “likes” a certain feature. User research is hard.

Another way to avoid sinking into this downward spiral is to make sure you are leveraging multiple frameworks. Does your product have the four fits? Does it have traction? Is it loved by some core audience? If you can leverage multiple different tools or thought frameworks and your feature seems to pass the test for each of them, you’re probably on the right path.

What is ‘Growth Thinking’? Part II: Lessons from Design Thinking

This is part II of a series of posts exploring and defining “growth thinking” by comparing it to other popular problem-solving frameworks. Need more context? Jump to Part I.

But first, what is design thinking?

“…the continuum of innovation is best thought of as a system of overlapping spaces rather than a sequence of orderly steps. We can think of them as inspiration, the problem or opportunity that motivates the search for solutions; ideation, the process of generating, developing, and testing ideas; and implementation, the path that leads from the project room to the market. Projects may loop back through these spaces more than once as the team refines its ideas and explores new directions.” —Tim Brown, IDEO

Design thinking is a creative problem solving framework that is human-centered, collaborative, optimistic, experimental, and evolutionary. Design thinking is positioned at the intersection of feasibility, desirability, and viability: what is desirable for an individual person and technologically feasible and economically viable? To find innovative solutions that meet all these constraints, design thinking prescribes a process of researching, prototyping, testing, and sharing. And, of course, constantly iterating through each of these phases.

If you’re interested in learning more, I recommend Change by Design by Tim Brown. If you’re looking for a shorter read (and into education), checkout IDEO’s Design Thinking for Education.

Divergent & convergent thinking

“To have a good idea, you must first have lots of ideas.” —Linus Pauling, Nobel Prize winner

One of the early phases when launching a new feature or experiment is to come up with ideas — lots of them. Good growth teams challenge assumptions, are creative, and aren’t afraid to take risks to try new ideas. But good growth teams are also vicious at prioritizing: no matter how exciting an idea is, if it isn’t impactful, it shouldn’t get prioritized.

This strategy aligns with the divergent and convergent phases in design thinking. In the divergent phase, you open the doors to try new things and don’t close the door on ideas that might have potential. It is amazing what can happen when you push yourself to look for more ideas; It’s good practice to avoid committing to your first idea until you’ve generated several alternatives (At DataCamp, we loved the “Crazy 8s” exercise). But to make sure you are having the greatest impact you can, you also have to be critical and kick less important ideas to the curb, just like you converge on a shortlist of possibilities in design thinking.

On the Growth team at DataCamp, our weekly meeting schedule followed this divergent/convergent pattern: we schedule ideation sessions (divergent thinking) followed by a proposal meeting where the best ideas are pitched to the group (convergent thinking) followed by a refinement session where everyone can help tweak the ideas (more convergence). Then the next week, we start back at the beginning again.

Optimism: things can always be better

“Curiosity does not thrive at organizations that have grown cynical.” —Tim Brown, IDEO

One of the unspoken truths about the mindset of a successful growth team is that you can always improve your product and your business. In our day-to-day, it is easy to take this for granted, but continuous optimism is a crucial component of a team’s success. I was fortunate to work with an amazing team at a company where this attitude is not only welcomed, but is considered the standard. Without optimism, why propose experiment ideas at all?

Growth teams require insatiable curiosity — ”What would happen to conversions if we change our onboarding?”, “Is our pricing page too slow on mobile devices?”, “Are we recommending new users the best first course for them?” — and without the belief that things could be better, this curiosity will dry up.

Empathy

Often, we find areas of opportunity to improve our product in places where we feel we are not meeting our users’ needs. This gut instinct comes from constantly trying to understand our users. At DataCamp, thinking about individual learners’ experiences as they move through our site — rather than solely relying on summary statistics about thousands (or millions) of users — gave us a much deeper understanding of the people we were building DataCamp for.

This type of human-centeredness is a core component of design thinking and is one of the biggest differentiators between design thinking and many other problem solving frameworks. By observing and listening to users, we are able to think creatively about new ways to address their specific needs. If you’re not already, conducting user interviews, collecting survey data, watching screen recordings, reading net promoter score feedback, and skimming through support tickets are all excellent ways to help understand your users as deeply as possible.

Our team was also extremely data-driven, which in some ways makes it even more important to be empathetic to our users. Not enough can be said about the power of mixing quantitative and qualitative data to tell a more complete story. Quantitative data is great at giving insight about how most people are behaving, but more personal (often qualitative) attempts at understanding users have two benefits:

First, we can gain fascinating insights from people at the edges of the spectrum, like power users or people who churn early on.

Secondly, it is a powerful reminder of the impact that our work has on actual human beings. Trying to understand our users as deeply as possible should be a constant effort because it makes it easier to both identify potential problems and propose potential solutions.

Define the problem

One of the reasons that the process of design thinking is so iterative is to make sure that you are addressing the right problem from the beginning (this is also why the first phase of tackling a project using design thinking involves extensive research and observation). As a growth team, we are constantly faced with complex and convoluted challenges. If I’ve learned anything from running split tests, it’s that things that seemed like simple and intuitive fixes often turned out in unexpected ways.

Defining the problem is also especially important for running experiments. To be able to run an experiment, you have to be able to explicitly define a hypothesis that includes what you think the problem is and how your change will improve it in a measurable way.

It is important to be specific. A bad problem statement could be “Our homepage doesn’t convert enough visitors.” A better problem statement could be “Some visitors who land on our homepage don’t convert because they are confused by the technical buzzwords that appear at the top of the page”. The learnings from a test centered on the second problem statement will be a lot more interesting.

Embrace constraints

Although it may sound counterintuitive, constraints are crucial for doing creative work. Adding constraints can help reduce feeling overwhelmed by choice, or the writers-block-equivalent for growth teams (feeling stuck and unable to come up with innovative test ideas).

In reality, sometimes you don’t need to place constraints on yourself or your project — they are already there. For example, at DataCamp, there was a time when our Campus app (the main learning interface for our online courses) didn’t work on mobile (and it wasn’t designed to — at the time, we believed writing code on your phone was a little crazy). We had a lot of mobile traffic and many of our paid ads were viewed on mobile, but it would have required a full rewrite of the app to make it work properly on small screens. We spent a daylong design sprint trying to solve this particular challenge, with the constraint that making the Campus app mobile-friendly was not technically feasible. With the constraints, the team came out of the sprint with some great solutions.

But sometimes, you need to set constraints in place yourself. For one of our first design sprints at DataCamp, we tried to propose solutions to improve our learner dashboard. The problem is that the dashboard is used by a wide variety of user personas and often they have different motives and goals. Without placing constraints on what specific problem we were trying to solve, we ended up not coming away with much at the end of the sprint. Had we placed specific constraints — like the constraint we had when working on the mobile conversions sprint, ”we cannot change X due to technical limitations”, or “we are only focused on improving content discoverability for user persona Y” — I believe the sprint would have been far more productive.

Products, experiences, and tests: differences between growth thinking and design thinking

We used strategies from design thinking all the time on the Growth team at DataCamp. But there are some key differences between growth thinking and design thinking. Although our team’s long term goal is to improve our learners’ experience, the immediate way we do this is by running experiments. We were not a product team, we were the experimentation team.

Although experimentation is an integral part of the design thinking process, for our team, it was one of our end goals (the “things” we created were experiments). Sometimes we needed to be able to use the tools of design thinking in two different ways simultaneously: how might we design a better user experience, and how might we design a suite of tests to help indicate what a better experience could look like?

This is one of the meta-challenges I am excited to continue to think about. Specifically how can a team combine tenets of design thinking to create growth tests most successfully? Do you design a new experience (based on your understanding of your users), then break it into chunks to test and iterate from there? Or do you design many small, narrowly-focused experiments that will eventually contribute to a new design for a user experience?

I love Dan McKinley’s thoughts on iterative product development.

Conclusion

Both design thinking and growth thinking are based on series of rapid iteration, are experiment driven, require boundless optimism, and can benefit from understanding and empathizing with the people your product is for. Hopefully throughout this exploration we’ve started to piece together part of the definition of “growth thinking.”

What is ‘Growth Thinking’? Part I: Introduction

The concept of a growth team is a bit of a trendy topic in the startup/tech world. But it is a popular idea for good reason: companies like Facebook, Airbnb, Uber, and others have attributed significant improvements in their business metrics thanks to work done by growth teams.

What is a growth team? Growth teams are typically interdisciplinary, data-driven teams whose work touches marketing, product, engineering, and data science. Growth teams apply the scientific method to quantifiably improve business metrics — whether it is engagement, retention, conversion, or acquisition — often using tactics like experimentation and A/B testing. Growth teams are amorphous and flexible and are organized differently at different companies. In this series of posts, I won’t be trying to define what a growth team does; instead, I will focus on why good growth teams are successful.

There’s a lot of reasons why the model of a cross-functional, high-paced team focused on scientifically improving business KPIs works. One of them is the unique problem-solving toolkit used by growth teams around the world; I call this “growth thinking.”

Growth is a tool: In knowledge work our tools are the processes we use to approach and solve different types of problems. — Andrew Chen

Growth teams are typically composed of members with different expertise, like marketing, design, engineering, and product management. Everyone on the team brings different perspectives and experiences to the table, including different problem-solving toolkits (this is one of the many reasons why diversity is so important).

When a plumber shows up to a job and an electrician shows up to a job, they come with entirely different (physical) toolkits. In the knowledge economy, your problem-solving framework is your toolkit. Someone from a design background not only brings their design skills, but their domain’s specific method for creative problem solving. The value of an interdisciplinary team isn’t just the skills that each individual contributes, but the variety of problem-solving frameworks that come from having diverse backgrounds and perspectives.

A growth team’s one goal, eponymously enough, is to grow the company. But growing a company is a notoriously hard problem. Because of the diversity of roles and backgrounds on a growth team, growth teams are especially equipped to take on big challenges: they have lots of different problem solving tools in their toolkit, all on a single team.

Interdisciplinary work is when people from different disciplines work together. An antidisciplinary project isn’t a sum of a bunch of disciplines, but something entirely new. — Joi Ito

The way that successful growth teams think and work isn’t simply the same as the standard way of thinking from each of its member’s domains; something new arises when all of these different problem solving frameworks are mashed together. Joi Ito, the director of MIT’s Media Lab, describes the difference between “interdisciplinary” and “antidisciplinary” work: “Interdisciplinary work is when people from different disciplines work together. An antidisciplinary project isn’t a sum of a bunch of disciplines but something entirely new.” Growth thinking is more than the sum of its parts — it is its own problem solving framework. Growth thinking is not just interdisciplinary, but an antidisciplinary approach to growing a company.

Growth thinking may be new, but it isn’t original. In the spirit of Kirby Ferguson’s Everything is a Remix, growth thinking is a copy, a transformation, and a combination of several other powerful problem-solving frameworks, like design thinking, Eric Ries’ “Lean” framework, data-driven decision making, agile software development… the list goes on. These frameworks are themselves mashups and transformations of other theories that came before them.

In this series of posts, I’d like to compare and contrast how growth thinking intersects with other problem-solving frameworks, and share how I’ve thought about growth at DataCamp.

Continue to Part II: Lessons from Design Thinking

Designing for accessibility

Designing for accessibility isn’t just the right thing to do, it’s a key part of designing great solutions. Accessible solutions benefit everyone. Take curb cutaways: the ramps at the edges of sidewalks originally designed for people in wheelchairs benefit other people too, like moms pushing strollers or delivery people pushing carts. The company OXO started out designing utensils and appliances for senior citizens and people with Arthritis, and ended up making easy-to-use tools that work great for everyone. Designing a mobile app that works great on 3G connections will be lightning fast for someone on LTE or 5G. Designing for your users with the most requirements can help create even better solutions for everyone.

Inspired by Change by Design and User Friendly: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play

Managing up

Jared Silver introduced this one to me, and the concept immediately clicked. I worked at a company with a lot of first-time managers and a fairly flat organizational structure. If you’ve got a lot of critical thinkers whose work has them interact with different teams across the company, it is inevitable that those people will identify problems or solutions that their managers may not see. There will be times when you have to work together with your manager to accomplish things out of the scope of your own job, and “managing up” is a framework (that a lot of people have written about) to help you do just that.

Inspired by this post

The trap of big deals

For B2B startups—or startups transitioning to B2B, as was my experience—this will undoubtedly happen: The Big Deal™️ will come along, and unfortunately, you wont close it because you are missing a certain feature or certification. Naturally, it will be tempting to build that feature or spend time and money to get certified.

But the trap of big deals is the concept that in a resource-constrained environment (like most startups), you shouldn't spend your resources building those features or going after that certification unless your business is predicated on big deals. If you're the type of SaaS company that makes most of its revenue from small deals, you need to take them into account when choosing how to prioritize projects—which seems obvious. But it isn’t always so obvious to deprioritize a feature you know a big, potential client wants.

If you consistently prioritize work that you believe will help you close big deals and neglect projects designed to help smaller customers use your product, you'll end up building a product that isn't working for your core audience.

Inspired this post

Conway’s law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

—Melvin Conway

The wheel of value creation

I heard of this one from Weston Stearns. He presented this at a company all-hands at a time when focus on solving our users’ needs had taken a backseat. In essence, a company needs to balance three focuses: first, creating as much value for our users as possible; second, monetizing that value; and finally, investing that money to create even more value. It’s all about finding balance within the wheel of value creation. The wheel of value creation in the sky keeps turning.

The cargo cult and “bending over backwards”

I first heard of this concept when Dave Robinson pointed me to Richard Feynman’s 1974 commencement speech at Caltech. Good scientists “bend over backward” to compile all of the evidence against the hypothesis they are trying to prove, as well as evidence for it. Feynman’s speech is a good reminder to question both the macro idea—how do we know?—and the micro: how do I know this particular thing is true? We should always be on the lookout for pseudoscience.

Premortems

Jared Silver introduced this to our team. A premortem is a great way to get the gears turning to make sure you’ve considered all options before making a big decision. It goes like this: Imagine you and your team get called into your boss’ office in a few months because the project you’ve been working on has become a total disaster (for a more extreme version: imagine you are all getting fired). What could have gone wrong? It’s a fun twist on the classic pro/cons list, and works best when choosing between two potential options.

Cost of quality

The goal of almost any product team is to move as fast as possible and build a quality product. The “cost of quality” cuts two ways: there can be a cost of shipping something that is low quality, and there can be a cost to shipping something that is high quality.

The cost of shipping a low-quality product is degraded user experience (imagine bad reviews, lost customers, etc). But the cost of shipping a high-quality product is a decrease in your team’s speed.

Time is valuable, and spending too much of it polishing features or conducting extensive QA takes time, especially when the Pareto principle comes into play (the last 20% of the work could take 80% of the time). What is the cost of the chance of a few small bugs? What is the cost of starting the next team project a week later, but raising the quality bar of the current workstream?

The cost of quality is yet another area that requires finding balance.

Product/Market/Model/Channel fit

Another one from Brian Balfour and the good people of the Reforge program. In essence: product-market fit isn’t enough. Product-market fit alone could lead you into the “if you build it, they will come” fallacy. Does your product solve a need _well? _Is that need important enough that your users “can’t live without it?” Is there a significant group of people who have that need? If so you’ve found product-market fit.

But it goes on: do you have a monetization model that makes sense for your product and your market? Do you have a viable channel for new users to find your product? If so, you’ve found product-market-model-channel fit. A business will fail if it doesn’t find all of these “fits.”

Machine learning as translation into N-dimensional space

This is a mile-high, extremely oversimplified view of machine learning, but this idea helped a lot of various machine learning approaches click for me.

You start with very complicated data. You need to distill it down so you can plot it in space. There are all sorts of techniques to do this distillation. Once you can plot your data, you can do all sorts of math magic. There are lots of different types of math magic. The math magic lets you calculate distances between points and find clusters. Voila!

SaaS retention as an indicator of P/M fit

I came across this idea from Brian Balfour’s Reforge program. How can you tell if your product is providing value to the market, aka that you’ve found the infamous “product market fit?” One way is to look at your retention curves. You expect to see some early dropoff; not everyone you market to is your core audience. But if your curve flattens out, you have some powerful evidence that there is a market out there that is unlocking enough value from your product to keep coming back. If the curve doesn’t flatten out? Time to keep iterating on solving a deep-seated need for your users.

Inspired by this post