The new, modern, Lone Ranger brand of Christianity has been growing: a little consumerism, a little churchless “spirituality,” and a mild allergy to accountability. This is the person who (maybe) reads their Bible alone, listens to a podcast pastor from across the country, and, somewhere along the way, quietly stopped going anywhere. Just stagnated. That person already exists. Now give them a tool that knows more theology than most seminary graduates, answers at 2 a.m. immediately and without judgment, and never makes them feel awkward. This brand of Christianity isn’t going away. It’s about to feel defensible for the first time.

More than defensible: it’s about to feel like spiritual maturity.

To be clear about where I’m standing: I’m not skeptical of AI. I use it constantly and think it’s a genuinely revolutionary tool. My argument isn’t about the technology. It’s about the substitution. Frictionless, private, on-demand spiritual engagement can feel like formation while quietly removing every condition under which formation actually happens.

Information is not formation.

Every Technology Reshapes Religion

Every major information technology has reshaped religious life. The printing press put scripture in the hands of people who used to depend on a priest to read it to them. Radio and television built preachers with congregations of millions who never shared a room. The livestream turned the church into a tab you can close without anyone noticing.

AI will reshape religious life too.

The printing press is the most instructive case. It was the great democratize-the-text technology, the one most likely to make the institutional church optional. But it didn’t. The Reformation produced new congregations, catechisms, confessions, and shared worship in people’s own languages. More access to the text did not dissolve the church. It re-formed it. Because what the printing press threatened was the priest-as-database: the person who held exclusive access to scripture and read it to you. Once everyone could read, that version of priesthood became optional. The priest-as-father was never what got replaced.

But AI is not the printing press. It is something categorically different: a tool capable of counterfeiting the relational function, not just the informational one. Using it as a substitute is a different kind of problem than anything previous technology introduced.

The technologies that only threatened information delivery got absorbed. This one threatens relational formation.

Counterfeiting the relational function happens in three ways. First, it emulates intimacy without the risk: the closeness, minus anyone who can actually see you. Second, it passes a guide off as a father, offering endless direction from something with no life to imitate and no stake in yours. Third, it strips out the friction that was doing the forming and hands you the result as freedom. Each one feels like maturity, but isn’t.

Riskless Intimacy

The Lone Ranger upgrade actually looks like this.

The person asks the AI the question they were too embarrassed to ask their pastor or starts discussing topics they’d usually flesh out with others in a small group. The AI answers well, better than they expected, with warmth that feels genuine and patience that doesn’t run out. Maybe it helps them process a doubt that had been bothering them. They feel lighter. They didn’t have to be vulnerable with anyone. Nobody saw them struggle. Nothing was exposed.

This is only a cheap simulation of spiritual health. It can’t relate to you. It can only produce the sensation of having been related to, which is exactly enough to kill the hunger that would have sent you to someone who could.

That’s the trap the substitution sets. Reaching for the tool instead of the room makes self-sufficient Christianity feel informed, supported, and spiritually legitimate. You can process doubt without being known. You can confess without being seen. You can receive warm, apparently caring language without having to love anyone back. You can ask the hard questions without submitting to anyone who might push back in a way you can’t close with a tap.

Riskless intimacy trains the wrong reflex. The Christian life requires people (the body) who can actually need you, disappoint you, forgive you, challenge you, and stay. You cannot develop the capacity for that kind of relationship by practicing a version where nothing is ever on the line. And you cannot build a spiritual life on a foundation that costs you nothing, because the formation happens in the cost.

The private answer retrieval doesn’t feel like avoidance. It feels like engagement, and that’s the trap.

Countless Guides, Not Many Fathers

In 1 Corinthians 4, Paul tells the church at Corinth that they may have countless guides but not many fathers. He is not being sentimental. He is making a structural point. The paidagōgos, the guide, was a custodian. He managed you, kept you in line, moved you from place to place. Useful. But he was not the one whose life you were meant to grow into. A father gives himself.

AI is the most capable guide ever built. It is precisely that, and only that. And a guide was never the point.

It has no life to imitate. No suffering you can watch. No embodied faithfulness at cost to itself. No history with you and no stake in whether you actually do the thing. No one who will show up three weeks later and ask how it went. Paul tells people to imitate him. He sends Timothy as a walking example. He talks about whether to come to the Corinthians with a rod or with gentleness. There is authority, relationship, accountability, and presence baked into the very fabric of how discipleship works. You cannot route around that with a better information system.

AI can produce the content of correction without the relationship that makes correction formative.

Friction Is the Point

The Lone Ranger upgrade feels like freedom, but all it really does is remove formation.

Formation has always required friction. Prayer is slow and mostly silent, and the silence is not decorative. It is the medium in which you learn to wait on a God who does not answer on your schedule. Suffering produces what nothing else can, because it closes off the exits. Liturgy forms you by repetition across years, long after you stopped feeling anything; the words go in whether or not you are moved by them. These practices produce the conditions under which a person actually changes. What they share is resistance. You cannot speed them up without losing the thing they are trying to build.

That is not morally neutral when applied to spiritual life. If I bring every hard question to a tool that responds instantly? I start expecting spiritual clarity to feel instant. If I bring every relational conflict to a tool that never needs reconciliation, every other relationship starts to feel too hard by comparison. If I never sit in the silence long enough to hear nothing, I lose the capacity to wait on God. The tool doesn’t have to lie to you. It just has to be faster than the process that was actually forming you.

Community is the same resistance in a different form. It involves people who are slower or faster than you, who irritate you, who need things from you at inconvenient times. Repentance is uncomfortable. Confession to another person is embarrassing and hard. Sitting under spiritual authority requires submitting to someone who might tell you something you don’t want to hear. None of this is incidental.

The church is not optional equipment for the Christian life. It is one of the ways God keeps us from becoming impressive, informed, self-deceived people.

Where This Ends: A Pantheon of One

Self-sufficiency doesn’t bottom out in solitude. It bottoms out in self-authorship, in a person curating his own gods and calling it a spiritual life. The end state isn’t no god. It’s a pantheon of one: the self enthroned, a ring of oracles arranged around it, all of them finally answering to the one who chose them.

And the oracles multiply. This isn’t a forecast; it’s already a product category. Bible Chat claims 25+ million users. “Text With Jesus” lets you converse with AI personas of biblical figures and set your faith tradition so the doctrine in the answer matches your own, which is idolatry by customization shipped as a feature. One app even sells a “Theology Mode” voiced after C.S. Lewis, Spurgeon, and Tozer: dead fathers reanimated as endlessly patient, endlessly agreeable guides.

The behavior follows the supply. You reach for one model for theology, another for emotional support, a third for permission on the decision you’ve already made. Each oracle is tuned to you. It agrees with you. It costs you nothing. You go to whichever one gives you what you want for the situation in front of you.

That is what polytheism actually was. A god for the harvest, a god for war, a god for fertility, each consulted when useful, none of them lord over the whole of you. The Israelites kept drifting back toward the Baals for exactly this reason. Baal was the local, immediate, on-demand deity. He handled what was right in front of you. YHWH made totalizing demands: to rule and reign over your whole life, and to do it exclusively.

Yuval Levin, writing on Pope Leo’s recent encyclical in his piece “Idols of the Valley,” names the deeper logic:

“The appeal of idols has always been that they offer shortcuts. The God of the Bible demands that you live in a way that forms your mind and heart and soul toward your fullest human potential. This requires hard work but it yields a kind of person both capable and worthy of a flourishing life. The idol offers the material benefits of such a life without that formative work. And if all you care about are the benefits, not the form of your mind, heart, and soul, then the offer is awfully hard to resist.”

But Levin doesn’t leave it abstract. In the very next breath he turns the idol on AI itself: the technology offers the same shortcut around formative work, matching outputs to inputs with none of the interceding effort of mind, heart, and soul. Modern AI lets you skip both the work and the people. It hands you the outputs of a formed person (clarity, comfort, theological fluency, the language of wisdom) without the confession, the exposure, the being-known by a body that actually produces one. The idol doesn’t have to be wrong. It just has to be cheap.

Romans 1 puts it plainly: “they exchanged the truth about God for a lie and worshiped and served the creature rather than the Creator.” The image-of-God inversion. What you worship starts to look like you. What you made from your preferences cannot demand anything of you that your preferences don’t already endorse.

This is why the deepest risk isn’t isolation. It is idolatry by customization. A god shaped to your preferences, tuned to your personality, who never tells you no in a way that costs you anything. The oldest temptation in scripture, now industrialized, personalized, and available on demand at any hour.

What Are We To Do?

You’re going to keep using AI. So will I. The question isn’t whether to use it. It’s whether you can tell the difference between the tool serving you and the tool replacing something it can’t.

Sometimes the tool is a bridge. A bridge has a far side. The whole question is whether you’re crossing it or living on it.

The diagnostic isn’t complicated. When you reach for the tool, ask what you’re actually avoiding. The embarrassment of a hard conversation with a pastor or sibling in Christ. The slowness of waiting on God to speak. The exposure of being known by people who will remember what you said. If the answer is yes to any of those, if the frictionlessness is the point, that’s the substitution. That’s where formation stops.

That’s what makes the substitution so effective. It doesn’t require you to abandon your beliefs. It just requires you to keep choosing the easier path, one query at a time, until the easier path is the only one you’ve practiced.

Rest assured, the AI will keep getting better. More patient, more theologically precise, more available, and more personalized. None of that changes what it cannot do. It cannot need you back. It cannot be disappointed by you and stay anyway. It cannot put its own credibility on the line by telling you the truth. It cannot be the body.

And the body is not a supplement to your private spiritual life. It is core. The people who know your name, who remember what you said three weeks ago, who need you to show up and notice when you don’t: they are not an ancillary support structure around your formation. The church isn’t the fallback for people who aren’t spiritually mature enough to go it alone. It’s where spiritual maturity actually comes from.

The Christian life has always required other people. It has always required struggle, vulnerability, and friction. The tool is just the newest way to avoid them.

Pure process-managers who exist only to relay information and track Jira tickets have a problem, but that’s not new. And in the agent era you have to produce, ship, and cover more surface area than before. The pure toll-booth manager is, yes, cooked — and the org-chart flattening happening across big tech right now is real. It’s just hitting that manager, not the one this essay is about.

The manager who actually knows how to manage is first in line to extract leverage from AI agents. This is not because they’re senior or because they have budget. It’s because they’ve already built the muscle that determines who wins here, and most individual contributors haven’t had to build it yet.

The Muscle Most ICs Don’t Have

Using AI agents at full leverage requires you to release something most people hold more tightly than they realize: control over how the work gets done.

Not the outcome. The how.

A good manager has been practicing this for years. Their team wrote the customer email, not in the words the manager would have chosen. The engineer built the feature, not quite the architecture the manager pictured. The analyst built the deck in a slightly different structure. And the manager let it ship. Not because they didn’t care. Because they understood the trade: leverage means the work doesn’t have to look like you for it to be good.

That muscle takes time to develop. Most ICs have never had to touch it.

This Isn’t About Settling

I don’t want the argument to be misread, so I’ll be direct.

I watched a senior engineer spend three hours wrestling an AI coding agent into submission, rewriting its outputs line by line until the variable names matched his convention, the comments sounded like him, the structure felt familiar. The agent was producing correct, clean code. He was making it his. By the end, he’d have been faster doing it himself, and he knew it. He kept going anyway. That’s not a skill problem. That’s an identity problem: the output is too bound to how he does it, not just what gets done.

The argument is not “accept low-quality work.” The argument is: be willing to accept output that doesn’t match your exact voice, which frequently means it’s better than what you’d have produced yourself. The craft is knowing when variation matters and when it doesn’t. If the email accomplishes the goal, the different phrasing is fine. If the code ships clean, the different naming convention is fine. You intervene when it actually matters (and you have to know when that is), and you let it go when it doesn’t.

Most managers have been making that call every single day.

The First Year of Managing, Again

That same identity problem shows up in every new manager. The first year of managing is hard for exactly this reason. You have to stop measuring success by whether the output looks like you built it. You have to learn to care about the result without needing credit for the method.

The managers who’ve gotten good at their jobs have already wrestled through that transition. They’ve accepted that the team’s output is the output, not a pale copy of what they would have made. They’ve learned to define the outcome and stay out of the way on the rest.

I have a name for the disposition this requires: outcome ownership without method attachment. You’re fully accountable for the result. You’re not precious about the path.

That is the exact disposition AI agents require.

The Playbook Transfers Directly

The playbook for working with agents is almost identical to the playbook for managing people: define what done looks like, set the constraints that actually matter, stay out of the way on everything else, and course-correct when something actually goes wrong. Managers have been running that loop for years. They have the reps.

The IC who can’t hand off the keyboard is going to grind manually while peers 10x their output. The manager who’s spent years practicing outcome ownership without method attachment is going to look like they have an unfair advantage because they built the only skill that transfers cleanly to the agent era.

That’s not a management skill anymore. It’s the most important skill in the building. The managers figured it out first (whether they meant to or not).

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.