Somewhere between Tuesday breakfast and Saturday dinner, “basgetti” becomes “spaghetti.” The lisp disappears. The mispronunciation you found so endearing just… stops.

And you realize you don’t remember the last time they said it wrong.

Childhood doesn’t slam doors. It slips out quietly while you’re busy making lunches and answering emails.

The Apple Note

My wife figured this out early.

She kept a single Apple Note with every mispronunciation, every ridiculous observation, every tiny burst of kid-logic.

It worked until it didn’t.

We couldn’t share it. I’d miss things for days. We couldn’t attach their voices. We couldn’t filter or find anything without scrolling forever.

The words were there. The texture was gone.

So we built something better.

Little Quotes

Now when one of our kids says something worth saving, I pull down and type it in. If I’m quick enough, I hit record and catch their actual voice. Sometimes I snap a photo—the backseat, the park bench, the kitchen table at 7am.

Each kid has their own timeline. Years from now, I’ll scroll back and watch their language grow—from toddler nonsense to surprisingly sharp observations.

And it’s not just me. My wife adds quotes when I’m at work. The grandparents add them when they’re babysitting. Everyone sees updates instantly.

When you half-remember something they said about the moon three years ago? You search it, and it’s right there.

The real feature

Kids don’t announce the last time they’ll say something in that tiny voice. The moments just slip, unceremonious and irreversible.

Little Quotes is how you pin them to time instead of letting them vanish.

In five years, you’ll want to hear those words. In twenty years, they’ll want to hear them too.

Download Little Quotes →

Learn More

You scroll through your notes app. Dozens, maybe hundreds, of ideas you captured because they seemed important. You recognize most of them. But if someone asked you to explain one of those ideas right now, without looking, could you do it?

I have hundreds of notes I can’t actually use. Ideas that seemed crucial when I captured them. Insights I genuinely believe. I can’t recite most of them because I never actually built the pathways.

Re-reading your notes is the learning equivalent of watching someone else exercise. You see the motion. You might even feel productive. But your muscles don’t grow. The metabolic work never happens.

The recognition trap

Your brain has two different systems for “knowing” something.

Recognition asks: “Have I seen this before?”

Retrieval asks: “Can I reconstruct this from memory?”

When you re-read your notes, you’re testing recognition. The words look familiar. That feeling is real. But it’s not the same as actually knowing the material well enough to use it.

Recognition is cheap. Your brain grabs the shortcut and mistakes familiarity for understanding. When you’re in a conversation or working on a project, when you need the idea and there’s no prompt in front of you, the retrieval pathway doesn’t exist.

Why difficulty matters

The stuff that feels productive is usually the stuff that does nothing. Re-reading feels smooth. Highlighting feels useful. All of them produce minimal retention.

The strategies that actually work feel harder. Retrieval practice feels effortful. Testing yourself feels uncomfortable, especially when you get it wrong.

But that difficulty is the point. The discomfort is a diagnostic. Ease is a sign of no adaptation happening.

When your brain has to work to reconstruct information, it strengthens the pathway. When you simply re-read, you’re borrowing confidence from the page. The page does the work. Your brain doesn’t.

This is why students who quiz themselves outperform students who re-read, even when the re-readers spend more total time studying. Effort matters more than exposure.

Doing the work yourself

Close the note. Try to reconstruct the main idea from memory. Struggle for it. Only then open the note and check if you got it right. That retrieval attempt, even when you fail, is the actual learning event. The struggle to remember is what strengthens the pathway. Space these attempts so they get gradually harder. Hit the edge of forgetting. That’s where adaptation happens.

From storage to working memory

Archives don’t make you smarter. They just make you feel prepared, like owning a set of weights you never lift.

When your notes sit in an app unused, they’re inert. You start every project from scratch even though you’ve captured ideas that would be useful.

When you force yourself to retrieve notes regularly, you’re testing ideas against your current thinking. You notice connections to recent work. You see which ideas have aged well and which need revision. That’s the difference between archived knowledge and working material.

What actually works

Stop re-reading as review. Hide the content first and try to retrieve it. Only check the answer after you’ve tried.

Build a spaced retrieval practice. Quiz yourself on key ideas at increasing intervals. Adjust based on difficulty.

Accept that retrieval feels harder. The difficulty is the mechanism. If review feels smooth, you’re probably not building much retrieval strength.

Use your notes to create. Write with them. Build products around them. Teach them. Integration is stronger than isolated practice.

The goal isn’t to remember everything. It’s to stop pretending that having notes in an app means you actually know the material. You don’t know it until you can retrieve it.

What I’m still wondering

When is forgetting actually fine? What’s the right tradeoff between memory work and just knowing where to look?

Does the mechanism change for different types of knowledge? Procedural versus conceptual versus personal insights might need different approaches.

Bible verses. Tiny cards. Jammed in my pocket.

I would pull them out in line at the cafeteria, on the bus, or waiting for class to start. Flip, read, repeat. No system. No algorithm. I was just trying to hang on to words that were shaping me.

Then I stopped.

I don’t know when it happened. Maybe work. Maybe building a company. Maybe just getting pulled forward by life. But somewhere along the way, I dropped the habit that had once meant a lot to me.

Over a decade passed. One day it hit me with that weird mix of nostalgia and loss.

I missed that little stack of cards.

Not for the aesthetic. For the feeling that I was choosing what I wanted to keep.

The forgetful one

I am a very forgetful person.

Not in a cute sitcom way. In a “remember the idea, forget the details” way. Concepts dissolve. Verses fade. Books turn into vibes that my brain files under “good (I think?).”

At some point, you start to mistake the symptom for the identity. The person who reads a lot yet reaches for something and comes up empty. The person who has to rebuild mental models they’ve already built once before.

Buying a better memory

All the apps. All the systems. All the promises.

Most of them worked fine in the mechanical sense. Cards showed up. Reviews happened.

But things kept breaking.

The tiniest bit of friction wiped out my consistency. If I needed to remember to open the app, game over. Any habit that requires remembering the habit is doomed to fail.

Beyond that, nothing in those apps helped me figure out the interesting frontier just beyond what I already knew. Nothing showed me the places where my understanding was thinner than I assumed.

It felt like I was collecting knowledge instead of growing it.

Companion for curiosity

What I wanted was the spirit of that old leather stack, but with a brain.

Something gentle. Always nearby. Something that helped me remember what mattered without feeling like I was clocking into a job.

I couldn’t find that feeling, so I spent the last year trying to build it. It’s called Etch.

Etch has two instincts. One helps ideas stick. The other goes exploring.

You capture the things you care about and they show up on your home screen at just the right moment so they actually stick.

Then, Etch looks at what you know and goes exploring on your behalf. It might notice you know hablar and comer and write you a tiny lesson about Spanish ‘-ar’ verb patterns. Or it might connect your saved Seneca quotes to that note you wrote about how you spend your time.

It feels less like another productivity tool and more like having a companion for your curiosity.

I kept it

When something lands, I drop it into Etch. When something sparks, Insights feeds it. When life gets crowded and I can’t read much, the system still keeps me connected to the ideas I care about.

There are mornings when I unlock my phone, and the Etch widget flashes a question I haven’t seen in a year, like some tiny line from a book I only half‑remember reading. And my brain answers it before I’ve even had coffee. It lands clean, like muscle memory I didn’t know I had. Quiet proof that something I cared about didn’t wash away. It stayed. I kept it.

It’s the same feeling I had with that old leather stack except now it actually sticks.

Make memory a choice

If you have also felt that quiet frustration of doing the work only to watch it fade. If you miss the feeling of actually keeping what matters.
I built Etch for that.

Think of the first few things you want to hold onto for real. A principle. A quote that hit different. A concept you don’t want to lose.

And when you’re ready, download Etch from the App Store and start etching them in.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

— Antoine de Saint-Exupéry

The year is 2016. Apple, at the peak of its iPhone dominance, makes a decision that sends shockwaves through the tech world. They remove the 3.5mm headphone jack from the iPhone 7. The outcry is immediate. “User-hostile!” “A shameless cash grab for AirPods!” Yet, Apple sells more phones than ever and, yes, a mountain of AirPods. Love it or loathe it, the move was a masterclass in a difficult truth: bold subtraction can unlock far more value than timid addition.

As product managers, we’re often wired for addition. Our backlogs bulge with “just-one-more-thing” features. Our roadmaps stretch optimistically into the horizon. Our dashboards become cluttered with toggles and options few ever touch. It’s natural pull of product development. Building feels like progress and keeps the squeaky wheels happy. But what if our greatest leverage lies not in what we add, but in what we bravely remove? Research suggests that when faced with a problem, we only consider subtractive solutions about 11% of the time. It’s time to flip that script and wield subtraction as the superpower it is.

1. Slash Feature Bloat

A product can bloat like an over-stuffed suitcase—every extra feature felt essential when you packed it, but now the zipper won’t close, travel is awkward, and you can’t reach the items that matter.

Case Study: Slack’s Strategic Pruning

In early 2024, Slack announced a significant cleanup: messages older than one year on free plans would be deleted, and legacy custom bots were slated for retirement in 2025. The initial reaction was a predictable flurry of concern. Yet, after the initial news cycle, something interesting happened. Usage, after a minor dip, rebounded.
Why? Slack wasn’t just cutting costs. They were simplifying. For new users, onboarding became less daunting. For Slack, infrastructure costs reduced. And strategically, it was a gentle nudge towards their paid tiers for teams needing longer-term archival and advanced bot functionalities. They didn’t just remove features; they clarified their value exchange.

Your Subtraction Playbook:

• The “Vision Litmus Test”: Regularly ask, “If we removed this feature today, would the core vision for this product still be achievable?” If the answer is a resounding “yes,” it’s a candidate for the chopping block.
• Usage Data is Your Scalpel: Don’t guess. Dive into your analytics. What features are ghost towns? What’s used by a tiny fraction but incurs significant maintenance? Cut with data-driven precision.

2. Demolish Technical Debt

Stripe has a mantra: Momentum Compounds, but the inverse is also true. Technical debt is the invisible anchor dragging down your product’s momentum. It’s the quick fixes, the legacy systems, the workarounds that seemed expedient at the time but now demand an ever-increasing tax on every new development cycle.

Case Study: Basecamp’s “All-In” Moment

Back in 2014, Jason Fried and the team at 37signals (now Basecamp) made a monumental decision. They had a suite of popular products: Backpack, Campfire, Highrise, and the eponymous Basecamp. Instead of juggling them all, they sunsetted everything except Basecamp, their flagship cash-cow.
The move seemed radical. They were voluntarily shrinking their product portfolio. But the result? A laser-focused team, a dramatically reduced surface area for bugs and maintenance, and the ability to invest deeply in making Basecamp the best project management tool it could be. They traded breadth for depth and velocity.

Your Subtraction Playbook:

1. Prototype Ruthlessly: Get that MVP, that quick-and-crude version, out the door. Speed is paramount in the early stages.
2. Validate Relentlessly: Confirm product-market fit. Is this solving a real problem for real users?
3. Refactor & Remove Savagely: Before you scale, before you pour marketing dollars, go back and dismantle the temporary scaffolding. Remove the exploratory code, refactor the hacks, and solidify the foundation. Don’t build your skyscraper on stilts.

3. Lighten Cognitive Load

Every button, every option, every piece of information you present to a user consumes a tiny bit of their cognitive energy. Too many choices, too much clutter, and you create “analysis paralysis” or, worse, frustration. Simplicity isn’t just an aesthetic; it’s a feature.

Case Study: The Evolution of Gmail’s Compose Window

Remember the early Gmail compose window? It was a smorgasbord of formatting options, CC/BCC fields, and attachment icons, all visible, all vying for attention. Compare that to today’s minimalist pop-up. Most of those options are still there, but they’re elegantly tucked away behind a single toolbar chevron or subtle icons. The primary focus is on the blinking cursor and the blank space, inviting you to write. Users aren’t navigating a flight deck; they’re drafting an email.

Your Subtraction Playbook:

• The “Five User Friction Audit”: Sit down and watch five real users attempt a critical task in your product. Don’t guide them. Just observe. Count their clicks. Note their hesitations, their moments of confusion. Where do they get stuck?
• **The “So Easy and AI Can Do It Audit”: Better yet, leverage an AI model with computer use capabilities and ask it to use your product. Turn on the “thinking” mode to see the models internal thoughts as it tries to navigate your UI and accomplish the tasks set before it. Simplify your app so that it’s so easy, even an AI can do it.
• The “Payoff vs. Pain” Matrix: For every UI element that causes friction, ask: “Does the value this element provides outweigh the cognitive load or interruption it introduces?” If not, it’s a prime candidate for simplification or removal.

4. From Frantic Motion to Focused Impact

In the world of product development, activity can easily be mistaken for achievement. Teams can be incredibly busy, shipping constantly, yet the core metrics barely budge. Subtraction forces a conversation about what truly matters.

Case Study: Twitter’s Fleeting “Fleets”

Remember Twitter “Fleets”? The Stories clone that appeared atop Twitter timelines in late 2020? It was a significant engineering effort, a clear attempt to jump on a popular social media trend. It generated buzz, some initial usage, and then… fizzled. Within eight months, Fleets were gone.
While it might have felt like a failure, the teams that made the call to kill Fleets weren’t just cutting their losses. They were liberating invaluable engineering and design resources. This freed-up bandwidth could then be redirected towards initiatives with a clearer path to long-term impact, like enhancing their subscription offerings or overhauling their ads API. They traded a fleeting trend for foundational growth.

Your Subtraction Playbook:

• The “North Star Alignment” Test:
  • Gold: Does this feature, this effort, this meeting directly and significantly move our primary North Star metric this quarter?
  • Silver: Does it support a crucial secondary metric or a strategic long-term bet?
  • Dirt: Everything else.
• Stop Polishing Dirt: It’s easy to get attached to initiatives, especially if a lot of effort has already been sunk. But if it’s not Gold or Silver, have the courage to stop investing time and resources.

Tools to Make Subtraction Your First Instinct

Building a subtractive mindset requires practice and the right tools to make it a habit, not an afterthought.

The Sculptor’s Mentality

Great products, like great sculptures, often feel inevitable. This isn’t just because of what’s been skillfully added, but because of everything that has been masterfully carved away. As product managers, we must cultivate the sculptor’s eye—seeing the masterpiece within the marble and having the courage to chip away at everything that isn’t the statue.

So, the next time you’re staring at your backlog or planning your roadmap, don’t just ask, “What can we add?” Ask, with equal rigor, “What can we bravely subtract?” You might find it’s the fastest path to shipping products that truly resonate and endure.

If you like this post, consider signing up to receive them via newsletter!

Introduction

Imagine launching a revolutionary software product, only to watch it fail spectacularly due to a fundamental mismatch between the system’s architecture and the real-world problem it was designed to solve. A nightmare scenario for any development team, yet one that is all too common in the high-stakes world of software development. The culprit? A lack of domain fidelity, a crucial but often overlooked aspect of the development process, can doom a software company to failure when they might otherwise be a rocket toward the elusive unicorn status.

In this article, we’ll dive deep deep into the world of domain fidelity and its strategic importance in preventing technical debt and ensuring long-term product success. We’ll discuss the risks of premature optimization, uncover strategies for achieving high domain fidelity, and learn from the Google’s missteps while launching Wave to illustrate the perils of low domain fidelity and premature optimization. Buckle up and prepare to navigate the treacherous waters of software development, where domain fidelity is your North Star guiding you toward success.

Defining Domain Fidelity: Aligning Systems with the Domain

Before diving into the risks of premature optimization and the importance of prioritizing domain fidelity, it’s essential to define what domain fidelity actually means. In the context of software development, domain fidelity refers to the extent to which a software product accurately reflects the real-world processes, rules, and requirements of the problem domain.

Achieving high domain fidelity is a critical aspect of developing any product as it ensures that the system or product closely aligns with the real-world needs of its users. This alignment not only makes the product more effective and efficient but also helps to minimize technical debt, as it reduces the likelihood of needing to make costly and time-consuming adjustments to the system down the line. By prioritizing domain fidelity, development teams can ensure that their products remain relevant and functional over time, even as the problem domain evolves and user needs change.

With a clear understanding of domain fidelity and its importance in the software development process, we can now explore the risks associated with premature optimization and over-engineering along with the strategies for achieving high domain fidelity in more detail.

The Pitfalls of Premature Optimization: Embracing Simplicity for Long-Term Success

While the nirvana for any software engineer is the perfectly designed system, focusing too much on building a “perfect” or “scalable” system early in the product lifecycle can actually backfire, leading to unforeseen technical debt. While this may seem counterintuitive, the primary driver of this explosion is when development teams invest heavily in creating a technically beautiful and scalable system without first testing its alignment with the real-world domain model.

In such cases, it becomes challenging to convince business partners to revisit and rebuild a system that was costly to develop in the first place. The result? A form of technical debt that arises not from the usual suspects – low-quality or hacky code – but rather from a mismatch between the system’s architecture and the real-world domain it was intended to address.

A more effective approach in the early stages of the product lifecycle (both for new features and the product as a whole) is to create a simple, “quick and crude” version of the product that focuses on solving the real-world problem. This approach allows development teams to test and validate domain fidelity early on, ensuring that their system’s architecture is grounded in the actual needs and requirements of the problem domain.

By prioritizing domain fidelity and embracing simplicity throughout in the development process, teams can reduce the risk of technical debt and create a strong foundation for long-term success. As the product evolves and its alignment with the real-world domain model is confirmed, teams can then invest in optimizing and scaling the system, confident in the knowledge that their efforts will be aligned with user needs and business goals.

The Google Wave Misstep: A Cautionary Tale of Overly Complex Technical Systems

Google Wave serves as an instructive example of a company committing to an overly complicated technical system without first testing and validating the design. Instead of prioritizing domain fidelity, the team prioritized future possibilities which ultimately led to the product’s failure and the need for a revised approach (getting out over your ski tips as some would call it).

Launched in 2009, Google Wave was a real-time collaborative communication platform that aimed to revolutionize collaborative work. It integrated various forms of communication, such as email, instant messaging, and document collaboration, into a single tool. The ambitious feature set necessitated a complex backend architecture to support seamless, real-time synchronization.

However, the premature optimization of this technical system proved to be Google Wave’s downfall:

1. Confusing user experience: The complex backend architecture translated into an overly complicated interface that users found difficult to navigate. As a result, many potential users (especially business decision makers) were deterred from adopting the platform.
2. Limited third-party developer support: The intricate architecture made it challenging for third-party developers to create compatible applications and extensions. Despite the existence of a plugin system, the complexity deterred many developers from spending time to build a robust ecosystem of add-ons and integrations.
3. Misaligned priorities: Google Wave’s development team focused heavily on creating a cutting-edge technical system but did not adequately consider whether the platform’s complexity aligned with users’ needs and expectations.

In response to the platform’s shortcomings and lackluster adoption, Google decided to discontinue Google Wave in 2010. The company later repurposed some of the technology into more focused and simplified products like Google Docs and Google Hangouts, which achieved greater success due to their streamlined nature and clearer use cases.

Embracing Domain Fidelity as a North Star for Development Success

As we’ve seen throughout this exploration of domain fidelity and its strategic importance in software development, prioritizing the accurate representation of real-world needs, processes, and requirements is crucial to minimizing technical debt and ensuring long-term success. In the race to create technologically advanced and scalable solutions, it can be tempting to lose sight of the real-world context in which our products operate. However, as the cautionary tale of the Google Wave illustrates, this oversight can lead to disastrous consequences.

So, what can we as product managers (and developers and stakeholders), take away from this?

First, we must ensure that domain fidelity is at the heart of our development lifecycle from the very beginning. By focusing on understanding and accurately representing the real-world domain, we can create products that genuinely address the needs and requirements of our users.

Second, we must resist the urge to prematurely optimize or over-engineer our solutions. Instead embracing simplicity and pragmatism in all stages of development, refining and scaling our systems only after validating their alignment with the real-world domain model.

By keeping these principles in mind and treating domain fidelity as our North Star, we can navigate the treacherous waters of software development with greater confidence, knowing that our efforts are directed towards creating products that deliver genuine value and stand the test of time. In doing so, we’ll not only minimize technical debt but also maximize the impact of our work, creating solutions that truly make a difference.

Building products is all about friction.

During the discovery phase you are identifying points of friction by talking to customers and finding out what parts of their workflow sucks.
During the design phase you are highlighting points of friction by creating mockups and design specs that showcase the new, frictionless workflow.
During the building phase you are testing the removal of friction by getting users to test your product and provide feedback.

Then the cycle starts over again as you interview customers who are using your products in their day-to-day work.

I was thinking about how this applied to my products and two questions came to mind:

1. What is product friction, really?

2. Is it possible to remove too much friction from a product? What happens if you do? (Spoiler: You can definitely remove too much friction, and your users are the ones who will suffer because of it.)

What really is product friction?

The best definition I have seen for product friction comes from an essay by Sachin Rekhi called The Hierarchy of User Friction.

“[Product Friction is] anything that prevents a user from accomplishing a goal in your product.” — Sachin Rekhi

In his essay, Sachin lays out the three main types of product friction: interaction friction, cognitive friction, and emotional friction.

Image Credit: Sachin Rekhi

Understanding these three types of friction is paramount to identifying and reasoning about what the right amount of friction is for your product, and when removing more friction would actually hurt your users.

You should definitely read Sachin’s post in full. He dives deep into why these are the three categories of friction and how they apply to building products, but, for now, a working definition of each will suffice:

Interaction Friction: Friction a user experiences when interacting with your product’s interface. This type of friction is centered around the UI provided by your product. This could be a GUI, an API, or a more tangible good. Whatever your users interface with to use your product falls into this category. While this is important, it is typically not the place people end up removing too much friction.

Cognitive Friction : Anything that increases the total amount of mental effort being using in working memory. Features or workflows that make your users think harder or longer about how to accomplish their goal fall into this category. This could easily be impacted by interaction friction, but doesn’t only include UI elements.

Emotional Friction: Emotions your users feel that prevent them from accomplishing their goal. This type of friction can be caused by your product, but many times this friction originates outside your product and it is your job to help alleviate it. Past experiences and the perception of others are main causes of emotional friction for your users.

Removing too much friction isn’t always a good thing

While removing all three types of friction is one of your primary jobs as a product manager, there can be too much of a good thing.

Removing too much friction from a product can have disastrous consequences. From hurting your users, to affecting other parts of your product, to collapse of an entire system, sometimes friction is what holds everything together.

Hurting User Safety

Your users want to accomplish their goal with your product is efficiently as possible, within reason. Most of your users are unlikely to offer up personal safety in exchange for any decrease in process friction.

Case Study: Robinhood

While you don’t want to optimize your product for the “lowest common denominator” or your least savvy user, you do want to make sure they can use your product safely.

Robinhood, a financial investments app, has significantly reduced the friction for buying and selling stocks, ETFs, and options. They have reduced it so much that you don’t even need to have a large sum of money to buy stock in your favorite companies because you can purchase fractional stocks.

The workflow is simple. Download the app. Sign up for an account. And viola! You are ready to start buying and selling. “Making your money work harder”, as the Robinhood slogan says.

People are raving about Robinhood. In fact, they just raised another large round of capital to continue removing friction from the process of investing. But the success stories aren’t the experience shared by everyone.

Investing money is risky. It isn’t responsible for everyone to participate. And you don’t want to encourage people to put money into something that could hurt them eventually. Unfortunately, the reduced friction created in the Robinhood app has enabled that exact type of behavior. Users are placing larger sums into riskier, option-based investments without understanding the volatility and risks. [This has caused many to lose almost everything they have].

Robinhood is doing a great thing in reducing the friction for people to invest. It helps level the playing field for everyone and that is a good thing. But they should also be equipping people to play the game. Leveling the field isn’t enough when the users who need your product don’t even understand the game at all. Balancing the removal of friction while protecting users from themselves isn’t always easy, but it is critical. Especially when the stakes are this high.

Case Study: Zoom

Users don’t always need protecting from themselves. Sometimes they need protecting from others.

Zoom has taken the world by storm during the mass exodus from centralized office meeting rooms to decentralized, digital video calls. Zoom is the clear leader in the space.

One of the reasons Zoom has become so popular is their easy-to-use meeting client. You can join from your browser or the app. It takes one click to join the meeting. And even if you don’t have the link, the meeting ID is only 10 digits long. Zoom removed a huge amount of friction users experienced joining meetings on other platforms such as WebEx and GoToMeeting. They also simplified the in-meeting experience. Making the UI fast and responsive while eliminating the need to click in multiple different places to see attendees and the shared content.

All of this reduced friction introduced a problem as more businesses, schools, and courts started using it. People were guessing meeting IDs, joining meetings they weren’t invited to, and “Zoom-Bombing” everything from corporate meetings to elementary classes. While sometimes innocuous, many of these events resulted in users of the Zoom platform being harmed emotionally.

As a response, Zoom has changed 2 key product defaults: 1) Requiring a meeting password that is embedded in the link and 2) forcing the meeting host to admit all users to the call explicitly. Both features add friction to the product, not eliminate it. And while it can be a pain, that is a good thing. Adding friction in key parts of the product likely wasn’t on the roadmap for Zoom , but responding to issues and adding it in was the right decision.

Impacting other parts of your product

Sometimes you may want to introduce friction in one part of your product to remove friction from and highlight other parts of your product. While we like to see each feature independent of others, most of the time the friction removed in one feature can impact the friction in another. As a product manager, you have to decide which features are your highest value and most important. These should be as frictionless as possible even at the cost of increasing friction in another place.

Case Study: Apple and the App Store

Apple has been feeling the heat lately due to their handling of some high-profile apps and their removal from the app store. This has sparked a wave of conversation about the App Store, Apple themselves, and why they can maintain such a tight control on the only way to install apps onto the most common smartphone in the world.

This all goes back to the value proposition Apple is actually selling with the App Store: Ease and Security.

The App Store isn’t the only way to install apps on an iPhone because Apple wants to do all the extra work of verifying every app that could get installed on an iPhone. It also isn’t the only way to install apps on an iPhone because they want to take 30% of all In-App Purchase revenue (though it may seem like it). The main reason why you can only install apps on an iPhone through the App Store is because Apple is removing cognitive and emotional friction.

There once was a time when there were many app stores for Blackberry and Android devices. You would have to determine which was the most reputable, cross your fingers that the app was any good, and hope it wasn’t some piece of malware about to steal all your data once downloaded. This emotional and cognitive friction was a priority for Apple to remove.

The App Store removes all cognitive and emotional friction from installing an app on an iPhone. You know it will be safe, you know where you are getting it from, and you know what other users have said about the quality of the app. As a result, Apple has increased friction (significantly) in other areas.

It is nearly impossible to sideload apps onto an iPhone and you can’t install third-party app stores from the App Store. This means things like Xbox GamePass aren’t available on the iPhone. To Apple, this tradeoff is worth it. They would rather maintain a low level of friction in the areas they see are most valuable to the majority of users at the expense of friction for the minority.

The collective system can fail

Last, but definitely not least, the removal of friction can cause entire systems to fail. When products are used at a large enough scale, removing friction can cause some to take advantage of the product in a way that wasn’t originally intended.

Case Study: Credit Cards

When credit cards were first introduced, they were intended to enable shoppers to purchase goods or services for which they didn’t have the funds readily available. They intended to pay back the debt in a reasonable amount of time or risked paying even more than they would have otherwise due to interest.

Over time, credit cards became ubiquitous. Every bank gave out high-interest credit cards to anyone who asked, and they asked for very little in way of proof that you were willing to pay back your debt.

Every person felt entitled to buy things they couldn’t afford and it changed the way we thought about wealth and money. The amount of held debt expanded in the 90s and early 2000s as consumers continued to utilize credit to buy things they had no ability to repay, such as cars and homes. Until it all came tumbling down in 2008.

Each individual person thought they were only impacting themselves. Their decisions to consume more than they could repay wasn’t affecting anyone else and it wasn’t that big of a deal… so they thought. This is a classical tragedy of the commons. Every person thinking it is no big deal that they consume more than their share until the whole system breaks down due to everyone acting in their self-interest.

While most of our products aren’t as ubiquitous as credit cards, it is easy to see that the removal of too much friction from the process in obtaining credit as well as utilizing that credit can cause disastrous outcomes.

How to determine when to remove friction and when not to

There are 3 main ways I try to think about friction when making decisions about where to remove friction and where to introduce it: 1. Go back to your product goals, 2. Define your biggest differentiator, 3. Think like your users.

1. Go back to your product goals

Assuming you have your overall product vision and goals in place, you should be using these to determine priority of removing friction. You don’t want to run around with a proverbial machete, removing friction from everywhere in your users workflow. Instead, think of removing friction more like a surgeon, carefully cutting and removing to ensure a balance between removing the bad parts while optimizing the whole.

2. What is your differentiator?

Knowing what your biggest differentiator should help you find places that you want frictionless. This should also help you pinpoint where you need to be cautious in removing too much friction. Keeping the parts of your product that are your key differentiators in your mind as you carefully cut friction will ensure you don’t sabotage yourself by cutting in a place you shouldn’t. Think like the Apple team does when deciding how users get apps onto the iPhone. You have to ignore some feedback to keep your differentiator perfect.

3. Think like your users

There are 3 types you users you want to be able to channel:

• Your most knowledgeable user: These users know exactly how your product works and understand all the risks. They can handle some responsibility as long as it doesn’t compromise your next user…

• Your least knowledgeable user: This user has no idea what to do in your product and may get themselves in trouble. Don’t remove the friction so much that they miss the bumpers and fall into the gutter.

• A nefarious actor: What would happen if a bad actor could exploit your most frictionless feature? How would they do it? What would the result be? This can be hard to imagine, but trying to put yourself in these shoes can prevent lots of headaches downstream.

Eliminating friction from your product is critically important to building something users want. Most of the time, you want to focus on how you can remove as much friction from the product as possible. However, while you are working on removing product friction, be sure to keep in mind that not all parts of your product are created equal and sometimes removing friction can cause more harm than good.

What are some other examples of products that removed too much friction? Post them in the comments below and I will share them on Twitter!

“It isn’t the customer’s job to know what they want.” - Steve Jobs

A couple months ago I wrote about the Problem Space and the Solution Space. The main idea of the article, if you haven’t read it, is that product managers should be spending an unbalanced amount of time in the problem space. You are the one in the organization who has the opportunity to do so and you owe it to your team to do it well.

What does this have to do with customer interviews?

Knowing what your customer needs is squarely in the problem space. To wholly understand the problem space you must know your customers needs better than they know them.

But knowing your customers needs more than they do is impossible if you never talk to them.
Enter: customer interviews…

What are customer interviews?

Talking to your customers on a regular basis and calling it a customer interview is not enough. These conversations may help you come up with new ideas for the product and make your customers feel heard, but they aren’t customer interviews. Talking to your customer without a clear goal is not a customer interview.

Customer interviews are a structured conversation with a specific goal in mind to help further the product vision and mission.

You will want your customer to be ready for the interview and know what you intend to talk about. Don’t blindside your customer, let them know you are wanting insights about your product and will come prepared to lead the conversation.

You are likely to learn a lot of different things while doing customer interviews. These include customer frustrations with their current workflow, new feature suggestions they want you to add to the product, and complaining about how your team doesn’t get bugs squashed fast enough. All these things are great feedback to use when deciding what you should be working on next. However, not all the information is created equal.

How to interview a customer

There are dozens. of. articles. out. there. about. the. top. questions. to. ask. during. customer. interviews. This is not one of them.

You can have an amazing list of questions planned out and afterwards feel really good about your interview yet still accomplish nothing. You need a specific goal to accomplish in your interview to make it worth your while.

Go into every customer interview with a specific goal in mind and use the right type of interview framework to accomplish that goal. Don’t let the customer take you down rabbit holes you don’t want to travel. Help keep them on track by choosing a framework that suites the goals you have set out for the interview.

The important thing to remember when performing customer interviews is: don’t reinvent the wheel. There are too many resources and frameworks out there to utilize. Find one that fits your needs and run with it.

Customer Interview Frameworks

Each of these frameworks illicit different types of feedback and accomplish different goals. You will want to pick which to use based on your relationship with the customer and what stage your product is in.

All products follow a basic pattern of “ideation/design” to “building” to “operation”.

Ideation/Design is the phase before you have a product. You are likely building requirements, testing the market, and trying to figure out what to build.

Building follows ideation/design and includes all the time you spend working on the product until you launch it into production. I would consider any products that are in a limited “beta” release part of this stage.

Operation is when you have a product in production being used and depended upon by customers. This comes with its own challenges and needs that even products in public beta don’t experience.

You should be talking to your customers during each of these phases, but your goals and informational needs will differ between them. While you can use any of these interviewing techniques and get some value from the interview, you shouldn’t settle for “some value”. Choose the framework that will get you the most value possible.

1. Voice of the Customer

Optimum Phases: Ideation/Design, Operation

Goal: Create a prioritized list of customer wants and needs.

VoC Overview

Voice of the Customer can be a specific interviewing type and a goal in one. Listening and collecting the voice of the customer will make your product better in nearly every metric you measure.

Searching for the Voice of the Customer results in a detailed list of the customer wants and needs. Use this as an opportunity to look at your product from the eyes of another. They will highlight things you don’t see.

You should leave this interview with 4 things:

1. A complete set of customer wants and needs

2. In the customers own words

3. Organized in a structural hierarchy by the customer

4. And prioritized by the customer by relative importance

VoC Resources

• VoC and JTBD Combined

• Simplicable.com Overview

• 4 Parts of the VoC

• 4 Tips for VoC Interviews

VoC Shortcomings

Don’t let customer ideas be your only source for innovation. It is their job to tell you the challenges they have, it is your job to find an innovative solution. Sometimes customers will have innovative product ideas, but most of the time these are short-sighted and over-optimized for one type of user… them.

2. Jobs to be Done

Optimum Phases: Ideation/Design, Building

Goal : Create a job statement to align why customers hire your product.

JTBD Overview

The Jobs to be Done framework was popularized by Clay Christensen. The idea is that people “hire” products to complete a “job” for them. The best way to ingest this idea is to watch Clay himself explaining why morning commuters hire a milkshake.

When using the JTBD framework to interview, you don’t want to focus on buying process, criteria, or anything else that distracts from the actual job needing completing. Your only goal is to gain a deep understanding of the job the customer is trying to get done.

A good job framework must:

• be stable, changing infrequently

• have no geographical boundaries

• is agnostic of the solution itself

• be a process

JTBD Resources

• Know Your Customers Jobs to be Done

• JTBD Website

• Great Images of JTBD Framework

• What is Jobs to be Done?

• JTBD and the Milkshake

JTBD Shortcomings

The JTBD framework can be too abstract. This can lead to your customer not articulating their job accurately and you getting misleading information. Make sure to ground the conversation in reality and always ask for examples.

3. Follow me Home

Optimum Phases: Operation

Goal: Understand how the user interacts with your product in their natural habitat.

FMH Overview

The Follow-Me-Home framework has been popularized by Intuit CFO, Neil Williams. Neil suggests the best way to get information about how your user interacts with your product is to meet them where they typically use it. This means getting out of your office, driving (or flying) to where your user is, and watching them complete their daily work. You learn things about their environment such as how many times they get distracted, who/what else is vying for their time, and when they abandon using your product.

When you allow the customer to interact with your brand and your product in their natural day-to-day work, you learn much more than you could in a simulated interview setting.

FMH Resources

• Intuit Business Insider Article

• Contextual Inquiry (Another Name for Follow Me Home)

FMH Shortcomings

It can be challenging to meet a customer and not interrupt their flow simply by observing. This is almost like observing wavelengths of light — they act one way when being observed and another when not. You should use this method with customers multiple times so they become comfortable with you watching over their shoulder. Explain to them you don’t want any changes to the way they work so you get accurate information.

4. Focus Groups

Optimum Phases: Building, Operation

Goal: Collect quantitative data about user preferences.

Focus Groups Overview

Focus groups bring together about 6-12 people to test a product and gather quantitative feedback. These users are aware they are being watched and measured in how they interact with and experience the product. In some cases, users will assign measurements themselves on how much they like/dislike different parts of the product relative to others.

This method works great when A/B testing different mockups and prototypes to determine which route will provide the most benefit for the work required.

Focus Groups Resources

• Basic Overview

• Guide for running a focus group

Focus Groups Shortcomings

Focus groups typically require some other type of analysis or interview to have been completed previously. It is hard to perform a focus group without any product or mockup. Users also behave slightly differently and have different preferences when they are out of their normal environment (see Follow Me Home).

5. SPIN

Optimum Phases: Ideation/Design

Goal: Narrow down the problem space to something customers will pay for.

SPIN Overview

Created by Neil Rackman in the 1970s, the SPIN method was initially built for optimizing the sale of an existing product. This framework also works great when interacting with users during the ideation and design phases. SPIN stands for situation, problem, implication, and need-payoff. Each of these steps provide a specific insight.

Situation: You are looking to get background information about the problem space and as much context as possible.

Problem: Explore what makes their job hard. What things do they see could be done better? Ask a user what parts of their job they dread and which parts make them dissatisfied.

Implication: You should find out what the negative consequences are for not fixing the problem. This could include lost time, money, or customer satisfaction.

Need-Payoff: Here you will determine what a customer would be willing to pay to fix the problem. You want to find out what the positive consequences are for solving this problem.

SPIN Resources

• ProvenModels Website

• Examples of SPIN questions

• How SPIN is used in selling

SPIN Shortcomings

SPIN is not a fully fleshed out framework for product building and customer interviews. Because of this, there are not many resources on how to conduct these types of interviews and what types of questions to ask at each stage. You will have to get a bit creative and put in the hard work to get this one moving.

6. The Four Helpful Lists

Optimum Phases: Ideation/Design, Building, Operation

Goal: Find product areas on which to focus additional efforts.

4HL Overview

This framework is not only helpful for product interviews, but also for optimizing processes and teams internally. It was created by Tom Paterson and is one of the simplest frameworks on our list.

On a board, create 4 main columns:

1. What’s Right?

2. What’s Wrong?

3. What’s Confused?

4. What’s Missing?

Each of these corresponds to an action you will want to take when building your product: Amplify, Fix, Clarify, and Add (accordingly). Users can add items to each of the four columns in any order and in any quantity. This can be relatively quick or take many hours with a lot of discussion.

This interview tactic is most effective when you are trying to understand what customers like, don’t like, and want changed from their current state. This could be a new customer (not using your product) or it could be a long-time customer (using your product for years). This framework helps narrow down areas of focus across the product lifecycle.

4HL Resources

• Basic Overview

• Not quite product, but a good example

4HL Shortcomings

This framework is unlikely to get you very specific details about what a user is trying to accomplish and what their jobs are. You will need to follow up this interview with more specific interviews (such as Jobs to be Done) after you have narrowed your focus.

Just talk to your customers

Save this list for the next time you are about to do a customer interview. Identify the goal you are trying to accomplish, and use a framework to help you accomplish that goal.

All of these interview types will provide huge insights for your team and help you build something better than you would have otherwise. The most important thing is to talk to your customers as much as possible and optimize the format to match your goal.

When doing your interviews, remember what your ultimate goal is: live in the problem space and know it better than your customers know it. You should know their problems inside-out and upside-down. Only when you know their problem completely will you start to find the best solutions that even your customers wouldn’t have thought of themselves.

What frameworks are missing from this list? Add your favorites to the comments below and I will share them out on Twitter!

Everyone wants to build a product that is “future-proof”. But what does building something “future-proof” really mean? Does it mean that it will seamlessly translate to the next technological revolution? That people will still be using it in 50 years? That it meets a persistent need that will never go away?

These ideas are great ways to future-proof your product, but none of them matter if someone advances into your market and takes your customers. Your future-proofed product also means nothing if you can’t acquire users in a large enough market to stay relevant. As a product manager, your job is to ensure your product not only solves the customer’s problem today, but that it makes your company money and maintains its viability for your users long into the future.

Defining Your Market Space

One of the main things that must be done after a product manager has defined the problem space is to determine who the target market is, or define your market space. This step is critical to finding a problem that is both worth solving now and that will stick around for a while.

Defining your market space is limiting your scope to a selected group of users that you can sell your product to. These are the people that you make user personas of and the people that have your sales team knocking on their door. Every successful company starts out with a small, niche market and grows from there. Companies and products that try to boil the ocean in their first iteration and go-to-market plan will fail. They will be everything to everybody and nothing to nobody.

Instead, what you need to be is everything to somebody. Then you can grow into being everything for somebody+1, somebody+2, somebody+n. And if you start small, and grow your market space effectively, you will be the big dog and have the largest market share.

Why you need to start small: a short digression into business strategy

Peter Thiel famously coined the phrase “competition is for losers”. His main point is that competition, while valuable in determining that you have found something users want and is enough to take a bet on, will kill your company. You don’t want competition, you want a monopoly.

The easiest way to get a monopoly is to build a product that is at the intersection of numerous things. Your user base is small, but in need and you can serve them with a product that they will love forever. Once you have dominated this market, you can start to scale. Envision concentric circles with an ever-growing market share as you expand. You start small and niche, grow large and dominant.

This is where the idea of “escaping the competition” (also by Thiel) comes from. Your goal as a business should be to not have any competition. You want to have a monopoly on the market.

Every small company, niche, and non-monopolistic will tell people they have a monopoly at the intersection of a handful of industries. Every monopolistic company will tell people they are not a monopoly because their business is the union of a handful of industries. Most large successful companies go through this transition in their company lifetime where they slide from small, niche, and non-monopolistic into something large, successful, and monopolistic.

Understanding the Market Space

Once you have defined your market landscape (who you are going to sell to) you will need to make sure the product you build serves their needs better than anything else in the market. Two companies that have the same problem statement, but different market spaces will come up with a product that looks, feels, and behaves completely differently. In fact, many would think these companies are not even competitors in some cases because of the large differences in their products (think of the email apps Superhuman and Hey - case study on this is below).

But this is only enough to get started. Once you have dominated the market space you have defined, you have to shed that exoskeleton and grow into a larger, more competitive one. This means moving out of your smaller concentric circle and into one that is larger and has more potential. However, more potential means more competition.

Your users here likely have the same problem, but their outlook on that problem may be different. You will need to do a combination of two things as a product manager: 1) sell them on your vision for the solution to the problem and 2) tweak your product to fill the gaps where you can’t.

Selling them on your vision for the product

April Dunford has some of the best strategy and thinking around this. Your job is not only to sell the best solution in the market, but you also need to convince your users why your point of view is the best and how that inevitably makes your vision the best.

You need to tell a compelling story about why you are solving the problem in a way that the users want to experience it.

Your point of view of the market gives customers a chance to walk in your shoes. You want to tell them why you prioritize certain features, who the optimal user of your product is, and why that combination will lead to a meaningful impact for them. Your users will have never purchased or used a product like yours, so you will end up spending a lot of time educating them. Give them your point of view, how it compares to your competitors, and why your point of view is better.

Fill the gaps in your product

Your new market is going to have needs that your previous market didn’t have. You should be looking ahead and anticipating these needs. Add some of the more critical ones to the product before you launch into the market or you won’t stand a chance.

The best way to think about this is to think in terms of the Kano Model. The Kano Model tells us there are three kinds of features: necessary, expected, and surprising. You should begin market research to identify what types of features fall into each of these categories before you launch into your new market. Querying your future customers for insights on their workflow and problems will help you determine which features are necessary, expected, and surprising. Bucketing features in this way will help minimize feature bloat while ensuring your product meets the basic needs of your customers.

This does not mean you are going to do all of them, in fact, you shouldn’t. You are selling a vision that completely changes the way they work. Don’t compromise that vision because they tell you something is necessary. It may not be. But, you should do a few things:

Be sure you have all the necessary features baked.

They just won’t use your product if you don’t. These are the types of features that provide a user the basic needs to do their job. Necessary features are like the wheels on a car, the product doesn’t work unless you have them.

As a product manager, you should be communicating with the business to determine what markets you are tackling next, begin doing your market research early, and get these things into the product.

Have a surprising feature as well

If you add in a surprising feature, you will win over customers that you didn’t think would leave their current solution. You should do some competitive analysis to determine what features your competitors have and build something different. Don’t overlap on this one. Stand out, build something compelling, and win your users with this.

Making the move

Once you have done this, you are ready to make the move into the next market space. You should ship early, often, and get as much feedback as possible. Your new customers will have complaints, and that is okay. Determine the right way to handle any complaints by separating the ones that are meaningful from the ones that aren’t aligned with your vision. A great way to do this is by using a product sieve, which I wrote about a few weeks ago.

Securing your monopoly for the long haul

It is easy and short-sighted to only look at current competitors in the market space you are moving into. The solution your target customers use today is definitely something that should be considered, but it is not enough to ensure you win. Remember, you don’t want part of the market share, you want a monopoly.

As a product manager, what you need to be doing is researching other companies that are not yet competitors. These are companies that have the same problem space you have but a different market space and thus a different twist on the solution. They may have different corporate values due to the market space they entered into, and they will sell the product differently because of that.

You should be looking at these “non-competitors” as your main competition for the future. They, too, are building their niche monopoly, growing into further concentric circles, and if you have the same problem space, your circles are going to overlap. This means that while you may not be competitors yet, you will be. And remember, you don’t want to have part of the market share, you want the monopoly. This means that one of you is going to win, and one will be left sucking wind wishing they had looked far enough ahead.

Leaving your problem space and strategy open enough

I wrote recently about defining a product sieve, and how important that is for building a good product. This becomes critical when you start to see your job as something that needs to consider not only current markets, but future markets and the changing demands that may put onto your product.

You will have to make changes to the way your product delivers value. Don’t lock yourself into a single strategy that will force you to lose. You don’t want to be Blockbuster who didn’t move into the age of the internet with the right strategy. Winner takes all, and Netflix won.

Case Study: Blackberry and iPhone

Blackberry and iPhone were two completely different devices solving the same problem in completely different ways. They both started out to do “computer” activities away from your computer. For Blackberry, this meant things like sending emails and consuming basic parts of the internet. For the iPhone, this meant consuming content. One was work and the other was fun.

The problem space was the same though — I need to do computer stuff away from my computer.

As the market space grew for iPhone and Blackberry, they began to compete. The iPhone started being more valuable for work, and Blackberry needed to find a way to keep up on content consumption. Unfortunately for Blackberry, we know how this ends… there is a reason I am writing half this post on an iPhone and not on an Evolve(?).

iPhone left their product strategy open enough to handle the future concentric circles they moved into. They built a device that was touch-only when business people said it “wasn’t possible for a work device to not have a physical keyboard”. They built work applications like mail and calendar into the app when their current target market underutilized the apps. They were thinking forward into the next circle and what was needed.

Blackberry on the other hand, added full-screen support later (remember the Blackberry Storm?…yikes). They were retrofitting their devices with features that were required for entry to the next circle, but they didn’t fit into their sieve. They realized they had started too well-defined and missed the opportunity.

Case Study: Hey and Superhuman

Let’s look at a more recent case study that hasn’t panned out yet, Hey and Superhuman.

Both apps have the same problem space. They both are solving for a default email experience that sucks where people want to get through their mail faster and in a more enjoyable way. Both companies limit their target market out of the gate to only people who are willing to pay money (a lot of it) for a different default experience. However, within that, they both have different niches and target markets and thus, aren’t competitors… yet.

Superhuman is after the executive who spends the majority of their day in email. They have a GSuite account for work and need to find a faster way through their inbox. They get hundreds of emails a day, some valuable, some not. They need to identify which emails are actionable, which are informational, and which need responses. And they need to do it all right now.

Hey on the other hand has a market of privacy-focused technologists. They don’t want to get through their email by using shortcuts, they want to get through it faster by getting less email. They don’t care about abandoning their email address for a nice, shiny @hey.com badge of tech nerdom. They just want email to be fun and relaxing, not stressful and anxiety-ridden.

Two completely different apps, built for different experiences, workflows, and cost, solving the same underlying problem. Superhuman has done a good job of capturing a lot of the tech market in their niche. They have their small monopoly and are probably looking at what comes next. Hey, on the other hand, is still too new to determine if they will get that monopoly on their market.

The real test for both apps will be how they respond to growing their market space. To continue growing their user base and their ARR, they will need to open up to a new target market. Doing this means they will soon find themselves competing. Superhuman needs to find a way to appeal to them more.

The goal for both companies should be to figure out where the concentric circles will connect. What market space they will be targeting when that happens, and to get started early by building features that start to draw that market in as early as possible. They both have something to learn from Apple and Blackberry… even if they start out with different market spaces, one of them is going to win and the other is going to Blackberry. Don’t be Blackberry.

So what?

As a product person, you need to do the following things to keep ahead of the curve.

1. Dominate your current market space. None of the rest matters if you can’t do that.

2. Stay ahead of the needed features for your future market space. You just won’t get any users if you don’t have their needed features.

3. Work with your marketing team to sell the vision, not just the features. Every time you enter a new market, you will lose on features. Other companies have been there for longer than you and have more features than you. Win on the story and viewpoint of the problem.

Keep your eyes down-road. Don’t spend all your time looking in the rear-view mirror and miss where you are headed. Dominate your market, start building for the next, expand the market, and repeat. You will find yourself escaping competition by carving out your monopolies along the way. Keep moving from owning a monopoly on the intersection of industries to a monopoly on the union.

It can be hard to define what makes a product manager successful. Their work speaks for itself, but putting your finger on what makes a great product manager successful and another fail can be challenging.

The same thing can be said for businesses. What makes one business a success and another a failure isn’t always apparent. Great founders fail all the time.

Warren Buffett, Chairman and CEO of Berkshire Hathaway, has a model for this: the Institutional Imperative. This concept has changed the way he invests in companies and how he chooses which leaders to bet on.

The Institutional Imperative

In his 1990 letter to shareholders, Warren Buffett defined a term he had used in the previous years’ letter:

Institutional Imperative , noun

“the tendency of executives to mindlessly imitate the behavior of their peers, no matter how foolish it may be to do so.”

• Warren Buffett, 1990 Shareholder Letter

Buffett suggested that institutions tend to fall into four traps which he calls imperatives. These imperatives are the default behaviors at most organizations who are not actively resisting them.

Buffett’s own words explain the 4 imperatives best:

“(1) As if governed by Newton’s First Law of Motion, an institution will resist any change in its current direction;

(2) Just as work expands to fill available time, corporate projects or acquisitions will materialize to soak up available funds;

(3) Any business craving of the leader, however foolish, will be quickly supported by detailed rate-of-return and strategic studies prepared by his troops; and

(4) The behavior of peer companies, whether they are expanding, acquiring, setting executive compensation or whatever, will be mindlessly imitated.”

• Warren Buffett, 1989 Shareholder Letter

Jeff Bezos, CEO of Amazon, has shared a similar model in his shareholder letters. Bezos calls it management by proxy. By “proxy” he means systems put in place to better the organization and their ability to service customers. The problem arises when the systems become the primary focus. They lose their intended effect. Management by proxy results in people saying things like, “I followed the standard process” instead of taking responsibility when things don’t go according to plan.

Having a clear understanding of the Institutional Imperative and management by proxy helps leaders in an organization see their blind spots and avoid traveling along the default path – what all leaders would do if not proactively minimizing the effects of the imperative.

The main argument made by both Buffett and Bezos is that leaders need to understand and actively work against these patterns in their business. Because they are so easy to fall into, most managers fall into these patterns by default, and don’t even realize they are doing it.

It is also important to highlight here that intelligence and experience have nothing to do with susceptibility to the imperative. Buffett says this was the biggest surprise he had when leaving business school – some of the smartest and most experienced business people fall prey to the Institutional Imperative and are blind to its effects. This is why it is important to organize your business to minimize the effect of the imperative.

While institutions as a whole seem to fall prey to the institutional imperative, product teams seem to fall prey to a different, yet similar, set of imperatives. Gone unnoticed and uncorrected, these imperatives will result in products that fail. Building a product while trapped in an imperative feels like chasing your own tail – you are constantly responding to the world around you instead of actively participating.

Let’s jump in…

The Product Imperative

The Product Imperative inherits its core from the Institutional Imperative, but highlights the default tendencies of a product team rather than an organization as a whole. As with the Institutional Imperative, product managers need to build systems and structures to ensure they minimize the effects of the Product Imperative.

The Product Imperative , noun

The tendency of product managers to neglect the important and challenging parts of their job. Letting other people and processes do the important work for them.

What I have noticed is that a product manager’s ability to drive true innovation and build successful, competitive products shrivels when the product imperative comes into play.

The main elements of the product imperative are the product manager’s tendency to

1. have a one-track mind, only considering a few solutions,

2. looking through the rear-view mirror at prior success instead of through the windshield at the potential,

3. allow the product to be prioritized by majority rule,

4. assume product success equates to product-market fit,

5. assume busyness is a good excuse for not creating a strong vision and strategy, and

6. allow the process to dictate their ability to execute.

Each of these can be easily overcome by acknowledging their existence and organizing your work to minimize their effects.

1. One Track Mind

The product manager locks themself into a single way of thinking about their problem space, crushing any hope of adopting a potentially more elegant solution to the problem. As a side effect, the product manager will find all data necessary to back up their decision to shut down any potential dialogue around alternative viewpoints.

This is rooted in how our brains work. Once you see something, you can’t unsee it. Known as First Conclusion Bias, we end up blinding ourselves by filtering everything through the lens of our first conclusion. Charlie Munger, Buffett’s partner at Berkshire Hathaway, has compared this to the sperm and the egg: the egg locks out all other sperm after the first is in. Similarly, we get the first conclusion in our head and our mind locks anything else out. This isn’t always a bad thing and in many cases (specifically those where the decision being made is reversible) can be beneficial. But when we are trying to understand and solve novel problems in the product, we need to be able to see the problem without tainting our point of view.

If the product is further along in the development cycle, this might also be considered the “Beautiful Baby Syndrome”. Every parent believes their baby is the cutest. Every creator believes their work is superior. And every product manager believes their product is perfect (or at least more so than it is). This is especially true when the product manager has owned the product since its inception, having worked tirelessly to build the product into something that is meaningful. Unfortunately, as the landscape changes, parts of a product become irrelevant and outdated. The product needs to be updated with the changing times. This requires deprecating or removing parts of the product that required blood, sweat, and tears to build.

Combat this imperative by trying to “see your problem with fresh eyes”. The easiest way to do this is by working backward from your end goal to redefine the problem. Doing this exercise is called inversion and it helps you see the problem in a new light. I wrote about how to apply inversion to product management a couple of months ago.

2. Rear-View Mirror and the Windshield

Resting on their laurels, the product manager sees prior success as a reason to not look forward. They see changes in the market or changes in technology as a burden rather than something that would help their product stay on the forefront.

When you are driving a car, the only way to stay on the road is by keeping your eyes down the road, where you are headed, and only occasionally looking in the rear-view mirror. Many product managers spend too much time looking in the rearview mirror, completely disabling their ability to steer their product down the right course.

I wrote in my essay on leverage that it is a product manager’s job to put on guardrails and keep the team headed in the right direction. And though you can drive on a straight road while looking in the rear-view mirror, it is only a matter of time before changes in orientation come. By the time you have responded it is too little, too late. This is the same in product. You may continue to have success while looking through the rear-view mirror, but you won’t be able to adapt to changes in the market fast enough to stay on top. It is only a matter of time before you are off course and struggling to maintain relevance.

Combat this imperative by only using historical facing data with a grain of salt. Find people who are the best thinkers in your problem domain and follow their work. They will give you a good sense of where the domain is headed, and what the view looks like through the windshield. Keeping your eyes down the road will enable you to adapt quickly and efficiently to any industry changes.

3. Decision by Majority

Lacking any true knowledge of the territory in which their product is deployed, the product manager allows anyone and everyone else to make the decisions for what their product features should be. They turn to sales, marketing, customer success, and the customer themselves to dictate the product roadmap and what problems the product should be solving.

Hear me on this: these folks should all have input. They have territorial knowledge too and are essential voices in directing your product to success. But the person who knows the problem best should be the product manager. Their job is to look beyond the (sometimes) short-sighted suggestions of others and find the true problem to be solved.

Many other people in the business suffer from the tendency to overgeneralize from small sample sizes. They hear a problem in a sales call, maybe hear it twice, and it sticks in their mind because they were uncomfortable being unable to say, “Yes, our product does that”. And while this may be a useful problem to solve, the product manager should be using everything else they know about the industry to determine the long-term value of solving that problem. Solving too many of these niche problems leads to finding yourself stuck in a local maximum, potentially with too high of an activation energy to get out and move toward the global maximum.

Product Managers that allow their product to be driven by the majority tend to end up with a product that is trying to “keep up with the Joneses”, matching the features of their competitors. Instead of taking a unique view of the problem and selling why you are better to the market, you end up competing in a race to the bottom on how cheap you can sell your product.

Combat this imperative with your marketing team. Help them put together the position statement for your product rather than just a list of features. Your sales team will be equipped to tell the market why you decided to prioritize certain features and why your product is the best solution. Selling your point of view of the world instead of selling your list of features changes the way customers view your product and enables sales to sell more without constantly needing new features to close a deal.

4. Confirmation Bias

Using sales metrics as the only indicator that their product is successful and solving the right problems.

There are many products that customers would rather not use, but they are the best of what is available. Hiten Shah recently surveyed twitter to determine if Zoom (the video conferencing company) had product-market fit. Turns out, they don’t. Most people wouldn’t be upset if Zoom went away tomorrow. But, they continue to purchase it for 2 reasons: 1) it is better than anything else available in the market right now, and 2) the customer (buyer) isn’t always the same as the user.

The split in the buyer and user perspectives can lead to a product that demos well, has more features than any other product, and looks to be the best value. But the product ends up not being used because it doesn’t solve the actual problem. Adding feature after feature (feature bloat) just to pad the list of checkmarks in a product comparison chart doesn’t mean your product is good nor does it mean your product is solving the intended problem.

If you looked at the usage metrics of Zoom, you would only assume they have great product-market fit. Unfortunately for Zoom, their users don’t feel like they solve the problem any better than anyone else.

Combat this imperative by looking at more than just product metrics. Product managers should be doing more than just looking at monthly active users, transaction rates, revenue targets, and new clients. These are all great indicators of a growing business and a sign that the product is doing something right. What these don’t mean is that the product is loved by your users and has product-market fit. Communicate with your customers and learn about why and how they use your product. You will learn a lot more that will guide where you take the product in the future.

5. Too Busy For My Job

A product manager who has no time for vision or strategy. They only have enough in the tank to execute what has been put before them. Falling prey to the business imperative pulls them like a black hole into all of the other imperatives.

Falling into this cycle will lead to a product that tries to advance on all fronts, doing everything under the sun and none of them well. The product manager will allow any decent opportunity to pivot the team, and ultimately leave most features half baked and useless. The product vision and strategy should be used by the product manager as a tool, used to determine what to say “no” to just as much as what to say “yes” to. Taking on too much will lead to an unusable product.

“You can’t advance on all fronts in all directions” - Peter Thiel

Product managers need to be in command of their product, deciding what features are being included and how they are tracking success. Don’t enable yourself to get “too busy” doing day-to-day work that you lose sight of the direction you are headed.

Combat this imperative by making time for your vision and strategy. You must be the person to define your vision and strategy. There is no way around it and no shortcuts here.

6. That’s Not The Process

The product manager forces their agile methodology even when it doesn’t make sense just because that is what all the other teams do. They have no use for thinking long term because their sprints are only two weeks long. They throw their hands up in the air when the business asks for more predictability while maintaining the short release cycles.

This is something Bezos would call management by proxy. Letting the agile methodology get in the way of doing great work. Sometimes it makes sense to be more flexible; allowing the team to work in a more flexible rhythm. Sometimes it makes sense to do the opposite, drive discipline to the process to ensure something gets done. But at the end of the day, throwing up your hands and not allowing any changes simply because “That’s how we do things around here” makes everyone worse.

Your job as a product manager is to inspire, lead, and lift the whole team. Make the people around you better. You can do that by listening to your team, being creative about how you provide the needed information to your stakeholders, and never letting a process manage your product for you. You are the product manager, not the Scrum process.

Combat this strategy by finding new ways to manage your stakeholders and the process you use in development. Listen to what your stakeholders are asking out of your team and the development teams, and use inversion to find a way to get you there. You will be lauded in the organization if you are actively looking for ways to meet the needs of your stakeholders while helping your development team partners stay focused on building.

So What Do We Do?

Warren Buffett says one of the most important things he and Charlie do when investing in a company is to find founders who are aware of the institutional imperative. This awareness brings forth action and mitigation to ensure they don’t become prey.

Just as with the Institutional Imperative, even the most experienced and intelligent product managers fall into these traps. It is not stupidity or incompetence that leads us into the imperative, it is simply the default and most worn path. Look for places in your work where you might be blind to part of the imperative. Organize your work to mitigate the risks of the Product Imperative.

Both the Institutional Imperative and the Product Imperative are a bit of a misnomer. Imperative implies they are inevitable, inescapable, and certain. But that doesn’t have to be the case. Being aware of each of these imperatives is the first step toward avoiding the trap. Combat each imperative with a clear strategy and purpose:

1) use inversion to see your problem with fresh eyes,

2) look through the windshield by seeking out the best thinkers in your industry and letting them show you what’s coming,

3) help your sales partners by enabling them to sell a point of view instead of a list of features,

4) remember that metrics don’t mean everything, talk to your users,

5) make your vision and strategy – just do it, and

6) manage your stakeholders and make the process you follow work for you, not the other way around.

Unlike a black hole, which has an inescapable pull, these imperatives are more like a treadmill. If you stop walking, or you trip, the treadmill will pull you back. Escaping the traps of the imperatives requires a constant effort. If you work against the default, find ways to structure your work, and keep yourself aware of the imperative, you can escape it. You have to constantly be working to not slip back into the default patterns of behavior. When you do slip, recognize it, identify what caused it, and move along with a new insight into how to avoid it in the future.

Thank you to the Compound Writing members who reviewed this post: Stew Fortier, Padmini Pyapali, Richie Bonilla, Josh Mitchell, and Kevin Shiuan.

Image Credit: Leo Gao

For years, there have been warnings that AI is going to eliminate routine, manual jobs. While this hasn’t yet come to fruition, the mood about AI and job elimination seemed to change this past week. GPT-3, an AI model that performs next-word prediction, plastered Twitter feeds with examples of how AI could not only replace manual workers, but knowledge workers as well.

I’m a skeptic. I don’t think AI will completely displace workers anytime soon. However, I also think there are valuable lessons in how AI models like GPT-3 generate novel content. These learnings can help us in our work now. AI such as GPT-3 may soon augment some of the product creation process, but the biggest help it provides is in showing us how to be better thinkers, and thus, build better products.

What is GPT-3?

The scientific paper describing GPT-3 was released back in June, and the API was made available in a limited, private beta this past week. And, for those of you who don’t spend all your time on Twitter, GPT-3 made waves with examples of how it could create websites from natural language, write product requirements based on a problem statement, and create novel tweets.

GPT-3 is an AI model developed by OpenAI. It is the third generation of the Generative Pretrained Transformer (GPT) models. GPT models are a type of machine learning trained with a large, diverse corpus of text. These models are not given a variable to predict during training—as is the case with supervised machine learning models—and are used to predict the best next word given a section of text. Because the performance of these models is highly dependent on the amount of data consumed during the training phase, the team at OpenAI upped the training set two orders of magnitude between GPT-2 and GPT-3. The training corpus for GPT-3 is essentially the entirety of the open internet as of October 2019.

How does it work?

One important characteristic of GPT-3 is that it requires priming to work. Priming is when you expose someone (or something) to a specific stimulus that then results in the identification of other things that were previously unnoticed. Here’s an example:

Imagine you are in the market for a new car. You want to be original but not too flashy, so you start looking for a Volvo. You poke around on Carvana, Volvo.com, and a few other car sites before deciding on a model you like. You still don’t feel quite ready to buy, so you put it on the back burner and hop in the car to get lunch. On your way to the fast-food joint down the street, you notice the exact car you were just looking at online! “What a coincidence!” you think to yourself. “I never see any Volvos out on the road, let alone the exact model I was just looking at.” Throughout the rest of your trip, you notice four more Volvos. This makes you wonder if you were original at all by assuming a Volvo was a less-than-popular car.

I am sure this has happened to you, if not a car then with something else. Nobody read your search history and bought a bunch of Volvos just to mess you with you. You just weren’t looking for them before. This is priming. Your initial stimulus was the decision that a Volvo is a fairly uncommon car so you looked at a few online. It’s only after this stimulus that you recognize there are more Volvos on the road than you thought (In fact, I bet the next time you are out driving on the road you will notice a Volvo. You’ve been primed by reading this example!).

Just like you need priming to recognize something you haven’t noticed before, GPT-3 needs priming to generate new content that hasn’t been seen before. The priming is done by providing a prompt as an input to the model. This could be the beginning part of an essay, a question, or even a partial block of code. All GPT-3 will do is determine what the best next word(s) is to complete your prompt and repeat that process until you tell it to stop.

Primers to Building

While GPT-3 is certainly an amazing step-change in the functionality of AI, it isn’t going to replace the generation of new product ideas anytime soon. The biggest reason is that it needs an effective primer to build anything novel. You need to see the world in a unique way to create a primer that generates a meaningful new insight. GPT-3 may become a very useful tool for product managers: changing how they write requirements, discover missing features, and validate new market opportunities. But above all, I believe it best serves as an example of how creating better primers helps us build better products.

The hardest phase of building any new product is making the decisions about novel features. These are the parts that are at the core of solving the customer’s problem. Often we try to do this by brainstorming with our colleagues. You stand next to a blank whiteboard, your colleagues staring back at you, waiting for someone to have an idea. When they finally say something, it seems fairly predictable, lacking any true ingenuity and creativity. Though this may be a common experience during brainstorming with others or by yourself, the thing that takes your decision making from mediocre to amazing is a good primer.

There are some basic things we can learn about creating primers by studying the types of primers that result in quality GPT-3 outputs. Just like GPT-3 needs a primer to generate output, product managers need a primer to create novel and valuable solutions to their customer’s problems.

1. The Medium Of Your Primer Matters

For GPT-3 to generate a novel bit of code, it needs partially complete code as the primer. To generate an answer, a question must be the primer. The generated output will match the format of the primer.

Our minds work in the same way. Some of the world’s best writers spend an inordinate amount of time reading. Reading is the same medium as writing (written language) and thus provides an effective primer to generating new ideas through writing. Reading not only helps you generate and realize new ideas to write about, but it also helps you become a better writer.

In the same way, artists paint scenes from the world around them. Their environment and the visual imagery they immerse themselves in inspires future works of art.

So what type of medium should product managers consume if they want to build better products? It depends on the task. If you are trying to generate new ideas for how to display data on a webpage, scour the internet for dashboards and data formatting tools. Take note of how they display information and use that as inputs to your design.

If you are trying to create a completely new product idea, you should be looking at niche and novel products that uniquely solve other problems. When doing this, look at the ways the product solves the user’s core problem. These nuggets of inspiration will get your mind primed for generating novel techniques to solve your user’s problems, even if it is a completely different domain.

Trying to convert from one medium to another adds cognitive load. Lower the activation energy of these new ideas by using a primer that matches the expected medium of your output.

2. Your Primer Should be Something Directional

But having a primer that matches the medium of your output isn’t enough. The primer must also direct your thinking around the specific problem you are trying to solve. Priming GPT-3 with something that is too open-ended and ambiguous results in aimless rambling unrelated to the user’s intended output. And, you guessed it, our brains work similarly. This is why writer’s block exists. You are staring at a blank page, unsure of what to write because there are too many options for what could come next.

When trying to design a new website, you don’t want to start with a blank browser shell. This provides too little direction. Instead, collect examples of elements you think look nice, choose a color scheme, and decide on a set of basic needs. Creating this palate of ideas will help you create something more valuable because it provides enough direction to get you moving and enough ambiguity to allow your creativity to shine.

A highly effective way to provide directionality in your primer is to leave an idea incomplete, even if you think you know the best way to solve it. Leaving a problem half solved allows your mind to wander, thinking about all the possible ways to complete the half-baked solution. Because our minds don’t like the cognitive dissonance of an incomplete problem, it is forced to think of ways to solve it.

3. Consume the Output of Your Work as an Input to the Next

If you are creating a feature list of what your product can do, use each new feature as an input to the next. This is something that differentiates the human ability to generate unique and cohesive ideas from models such as GPT-3. GPT-3 cannot understand what the previous inputs mean, only that they are a collection of inputs to generate an output. When you are building a list of features, you can understand how one might impact another, or how a basic feature could inform more complex workflows downstream.

The other thing humans can do that GPT-3 cannot is change the inputs. You can see how a design choice made previously acts as a poor primer to drive further development in other parts of the application. Changing the upstream design has large downstream consequences, both good and bad. Don’t be afraid to tinker with decisions that were made previously to see how they change the later outputs.

4. The Quality of Your Primer Matters

Writers don’t get better at writing by reading crappy books. Painters don’t get better at painting by looking at bland landscapes. Product Managers don’t get better at building products by studying boring solutions.

A primer that is both the appropriate medium and provides clear direction isn’t enough to ensure great output. The quality of the primer must also match the quality of the desired output. For product managers, this means studying highly creative and successful products (both niche and mainstream).

Increasing the quality of your inputs also requires a wider breadth of industries as inspiration. If healthcare companies never lifted their head to look at how other industries were managing data, electronic medical records would not exist. You should take time to lift your head, look out at other industries that have a similar core problem to yours, and take inspiration from the products that are solving it best.

Low-quality primers lead to low-quality outputs. But the inverse is also true. Always ask yourself if you are using the highest quality primers for your own thinking. If not, search for where can the highest quality inspiration be found. Only use the best possible primers for your product, it is the easiest way to increase the quality of your output.

TL;DR: With GPT-3 or Without It

Models such as GPT-3 may have a profound impact on how we design, build, and create new products. The future is bright and the possibilities endless for how this type of model could be applied. Whether or not GPT-3 truly has the capability to replace some knowledge workers is yet to be proven. Though while the applications begin to appear, we should take advantage of how these models can generate so much novel content. Identifying what makes a great primer and applying that to the way we think and build could have a profound impact on our ability to create.

Here’s how we can apply what makes GPT-3 great to our current product management style:

1) The medium of your primer should match your expected output medium

2) Your primer should be directional

3) You should consume the output of your work as a primer to any future work

4) High-quality primers lead to high-quality outputs

However, as we learn more about these generative models and what makes them work most effectively, we should adapt ourselves. The things that make the best primers for GPT-3 also make great primers for us.

Thank you to Josh Mitchell and Ross Gordon for reviewing this post.