It’s a metaphor.

But the last couple of weeks have made this literal — and it’s been surreal and delightful every single time.

I can’t stop thinking about it!

The Longstanding Metaphor

The phrase, let the product tell you what it wants to be, has always meant this: start building, expose it to reality, and through that process you’ll discover what actually needs to exist. As you iterate and learn, the product starts to take shape. Almost like it’s nudging you, whispering what’s not quite right yet.

As you learn from making and exposing what you’ve made to the elements, you start to understand what the product wants to be — in a way that you never could have based on theory and research before you really got started.

The product will tell you what it wants to be.

That’s all this phrase used to mean in my mind, and I’ve never been compelled to write about it.

Look Who’s Talking

But it’s no longer just a metaphor for me.

I’m getting toward the end of a POC (to de-risk the technical feasibility) for an AI voice-chat product in a niche domain, and this thing is literally telling me what it wants to be.

Like, out loud. In English.

I Can’t Wait to Test Discuss the New Version

When I finish making a change to the way I’m managing context — instructions prompt, tools available to the agent, or documents index for RAG retrieval — I’m no longer excited to immediately test it. I’m excited to talk with it about the changes.

The first thing I do after launching the app, rather than testing the changes, is to start a voice chat and say this:

“Hi, this is Dan. Please enter dev mode [allows it to break from persona and discuss technical topics, or anything out of bounds for typical conversations with users]. We just made changes X, Y, and Z — with the hope of improving A, B, and C. Can you see the new instructions about that? And does that all make sense? Any concerns or callouts?”

And then we have a conversation about the changes to the product. The product and I have a conversation. About the product. (What the hell?!)

It then, out loud and in perfect English, tells me what may give us trouble with the new version, what I should watch out for during testing, and ideas to try if those issues pop up.

Eventually, I say goodbye. I end the chat and start a new one, to actually smoke test or run planned eval cases — with fresh context.

Why Did You Do That?

When I move on to testing, I test until I encounter an issue. But instead of making a note of it, for later triage and analysis, I say this:

“Please enter dev mode. You just said X, but I think you probably should have said Y. Can you explain why you said X? Please include a rundown of tool calls with details and talk me through how you arrived at that response.”

And it does! It typically admits that it said the wrong thing — but it goes way beyond that. It may explain what data it accessed, where there was a gap in the information available, and that it tried to infer detailed advice in the absence of sufficient ground-truth information or instructions.

Or, it may explain that there’s a phase in the instructions that it took to mean X, when really I must have meant to prescribe Y behavior.

And then we brainstorm...

Dan: “What details from a tool call remain in context as the chat continues?”

AI Agent: “I’m able to reference the tool name, input string, and response data for each prior tool call in the conversation.”

D: “So you could effectively make notes to self as input on a tool call, if instructed to? And if instructions said to make a tool call that documents your full plan for every multi-turn interaction, you could then reference that plan to guide your step-by-step advice to the user across multiple turns?”

A: “Yeah, that would definitely work, actually!”

D: “So you could do that with one of your existing tools and ignore the data that comes back, unless it’s helpful in advising the user? Like just as a way of experimenting with this pre-planning pattern? And then we could add a dedicated tool for this purpose, if it’s working?”

A: “Yes, I think that would work well to validate the usefulness of the pattern.”

D: “Ok, then I’m going to update the instructions to request a plan up-front, which you’ll write as input to an existing tool you already have access to, and then we’ll test again to see how effective it is. Where in the instructions would work best for you to parse and leverage this new bit of instructions?”

A: “It would make sense to explain it after the XYZ section, toward the top of the instructions, to establish the importance of this new gating step in our workflow. But you may want to also give a one-line reminder at the end of the instructions, since recency is a factor in how I’ll weight the importance of content in the context window.”

D: “Ok, great. I’ll make the changes and talk to you again soon!”

It feels more like managing a team member, than it feels like testing a product in development. I offer feedback, and we work together to figure out how to optimize the agent’s performance.

(And that use of a tool call’s input as a way of allowing the agent to do notes-to-self and lightweight reasoning steps — even though the realtime model does not itself offer thinking/reasoning — has proven to be a winner.)

This has happened over and over in the last couple weeks, and I chuckle with wide eyes every damn time.

Leave a comment

I’ve been on lots of teams that build a product, but I’ve never had the product itself “on the team” to weigh in on how it could be better and next steps to accomplish that.

What’s the Lesson?

If there’s a lesson here, it’s not sunk in yet for me, I guess. This is not so much a lesson I’ve learned as it is a delightful experience that seemed worth sharing. Just because it’s so surreal.

As always, if you get started and listen carefully, then the product will eventually tell you what it wants to be. That’s happening already in this POC, and it’ll need to keep happening post-POC, in order for this product to make it out the door, find its place in the market, and win.

But also, if you’re building an AI product, the product may literally be able to tell you what it wants to be.

And that feels like a brand new thing.

Every family member I've known lived just upstream, as did my closest friends. Mom and Dad lived just upstream. My wife did too. Very close, in fact. Each of my kids lived just upstream — so close, we could wave to each other from our windows.

Upstream further, there were many folks I've known, but not so well. Some folks I've only barely met lived upstream too. Many people I've never met lived further upstream.

Everyone alive, and everyone who has ever lived, lived somewhere upstream.

What confused me most though were the neighbors I saw, when I turned to look downstream. There was Mom, Dad, Wife and kids. And everyone else I know — or ever will know. And everyone who will ever live.

All the good at my house came from upstream. The bad too though. It all flowed downstream.

When I was grown but just barely, I found a bottle in the river that was stuck on some tree roots, next to my house. Inside it, excellent instructions for balancing a checkbook. The bottle was dropped in the river at Mom's house, just upstream. No clue how it had gotten to her house, but I wish I'd asked her. Certainly had come from further upstream, just a question of whose house and when. If I think it will be useful for someone later, I'll be glad to send it downstream. Not likely at this point, but maybe.

The river flowed. It had been flowing for some time.

When Grandma died, I wrote a little note about all the things that had come downstream to my house from Grandma's house. A lot of them had made a stop at Mom's house, on their journey to me. Some at my uncle's house. I suspect a few even stopped at Dad's house, though I can't be sure of which.

Honestly, I think some probably stopped at my uncle's, on their way to my cousin's house, before making it to me — and then further on downstream from my house. In the dream, it was hard to keep track of the journey of each thing. It was so easy to forget what had come from where, if I ever knew at all. And where it was before that rarely crossed my mind — the stop prior, and every stop before that.

And I would guess that sometimes things got changed on their stops along the river.

But that little note, a way of remembering my Grandma and everything she'd sent downstream to me — to all of us — and then on past each of us to other folks downstream. That little note went into a jar, lid closed, and sent downstream. Mom pulled it out of the river to read it, when it reached her house. She told me she appreciated it. Felt like the least I could send down to her, after all she's sent down to me.

When something comes to my house, from somewhere upstream, I typically grab it and take it to my house. Somehow, I tend to keep it — but also send it further downstream. Not sure how it could be possible to do both, but dreams are funny things. "And you were there! But it wasn't you. We were at our graduation, but it wasn't our school." Things would come downstream, and I'd keep them. But I'd send them further downstream too.

Sometimes though, I took the things I'd gotten from upstream, and I'd bury them. When I realized they were bad, then I could bury them — but I sometimes couldn't tell. Dreams are so odd, like brain garbage. Funny, to not know a thing is bad, and want to keep it, and also send it downstream. But it happened a lot, which didn't feel very odd in the dream. I think because burying something bad was a lot of work, what with all the digging. Way easier to pretend it's pretty good, or at least that it's fine enough. Or maybe act like it just isn't there. Especially for big things that were bad. Burying something very big can be quite a project. It takes a long time to bury something really big, and it feels so hard. Blisters on hands and nothing to distract from the bad thing. Mostly hard though, and it feels so slow.

So, if I realized they were bad, then I might bury them. Certainly, I'd try not to send them downstream — but sometimes I did. In the dream, it was pretty hard to not send bad things downstream. I don't understand how it could be hard to not do something, but it made such sense in the dream. It never occurred to me how hard it was to not send the bad things downstream.

Felt pretty easy to not send the good things downstream though, so I'd send those downstream only sometimes. When I realized I was sending good things along, I hoped they'd make it far — lots of stops along the way.

The river flowed, like it had for as long as anyone could remember. Showed no signs of slowing.

Everything at my house came from upstream. The good and the bad. I had it all at my house, and I'd sent most of it downstream too. I'd buried some of the bad, so I didn't have to look at it — and so it wouldn't end up floating further down the river.

The weather along the river varied, from house to house and day to day. Some days the weather seemed just right at a lot of houses I could see. But the weather could also be troubling, even downright dangerous, at times. There wasn't much any of us could do about that.

Somehow, what flowed downstream to my house seemed mostly good, and I learned eventually how special that was. Why would so many good things make it to my house? I guess that's just dumb luck. I don't remember ever picking this house, and I certainly never got to pick what comes downstream to me. Even the things that weren't so great, I often found what was good about them. I sometimes managed to greatly enjoy the things that were just ok. I learned to sometimes get a good laugh out of something annoying showing up, or when unexpected rain ruined my plans. And even that inclination came from somewhere upstream, I suppose.

I could have buried more bad things, to make sure they don't make it further down the river. I could have sent more good things downstream, even new things that only I could make.

I'll do more of both.

This dream is an odd one. But an odd dream isn't odd at all. It makes no sense, which makes all the sense in the world. A dream that made sense would be the odd dream.

One part at the end did make sense though: I eventually wondered something. A question crossed my mind. Where does the river start, and who lives in that house?

And as soon as I asked the question, I was awake. And I started writing this, with a sense of deep gratitude to the place from which the river flows. To the house there, and to whoever lives in that house.

The funniest thing about this dream is what I've remembered as I've written it down. I've had this dream before. Every night, in fact. Every night of my life, I've had this dream.

And every day too.

"Picasso had a saying — 'good artists copy; great artists steal' — and we have always been shameless about stealing great ideas." 
—Steve Jobs, on Apple’s products

Tuesday morning of last week, I was drinking coffee, when I got a text message from a good friend and former colleague. He’s a very accomplished product designer and executive leader of creative teams. This designer-friend told me how impressed he was with Framer as a tool for making great-looking websites.

But it was the very next message in the thread that woke me up before the caffeine was in full effect: 

Framer’s interface is soooo similar to figma. Easy to use. 

So instead of innovating with original design thinking, they just copied Figma?  How lame, right?!  They must not be user-centric enough?  They must not be committed to great design? And this friend of mine must have been too far from actual design work for too long, to still care about genuine creativity? 

All of those thoughts appear to make sense on the surface, and I probably would have agreed with some of them earlier in my career. But at this point, I think they’re all wrong. Each of them is all wrong.

“De-sign” Is How It Works

The Internet mostly agrees that Steve Jobs was the first to publicly proclaim that “Design is how it works”.  Many have repeated this statement since.  It’s exactly right, but it’s a bit vague.  I think there’s more concrete implications hiding in the term “design” itself. 

Bear with me, as I approach the chalkboard for just a few seconds…

Design is a word composed of the root word “sign” and a prefix of “de-” (meaning “off” or “from”). In at least some sense, designing a product is the act of removing the “signs” from it, without rendering it harder to use. Decluttering is getting rid of the clutter. Designing is getting rid of the signs. 

We’re neither the first to notice this, nor to examine it — but doing so will help us get where we’re headed. 

The classic illustration of removing signs via design is the door at the main entrance of a large building, which Don Norman discusses in glorious detail in his classic book, The Design of Everyday Things. Do you push, pull, slide, or spin the door?  A poorly designed door will typically try to tell you, instead of show you.  

And how so? If you guessed with a sign, then you are correct! Typically the literal sign on the door will say either “PUSH” or “PULL” — depending on which side of the door you’re looking at. We didn’t think you’d be able to tell how to use the door, so we hung this sign for you to read.

But a well designed door needs no such signs.  The door itself makes it obvious how to open it.  It shows, not tells.  If the door needs a sign, then it was not well “de-signed”. 

There's much more that matters on the topic of product design (and many folks much more qualified than me to explain it all), but I’ve found this one thing is pretty fundamental. 

Design is how it works, and clarity is foundational to well-working design. 

Consistency Is Key to Clarity

But a product can’t offer clarity to its user, unless it is consistent.  Inconsistency is inherently unclear.  While it’s more of an annoyance than a true dysfunction, this is the fundamental design flaw of three-way light switches. 

Three-way switches are installed when two separate wall switches in a house are wired to control a single light — a separate switch on each end of a hallway, for example.  You don’t want to have to walk down to the other end of the hallway to turn off the hall light, and then walk back up the hallway in the dark to go to bed. So a switch on both ends of the hallway is useful.  The issue is the inconsistency these switches introduce to the experience of using them.  

With single-purpose switches (properly wired), “up” is on and “down” is off.  This is consistency, and it creates clarity for anyone who is feeling along the wall to find a light switch in the dark.  

Every time: find switch, flip it up, get light. 

Clarity!

But with a three-way switch, that clarity is lost: find switch, flip it up or down (but you can’t know which, because it depends on the state of the other switch, which you can’t see due to the darkness you’re trying to eliminate), get light (maybe). 

In abandoning consistency, the three-way switch has lost clarity. Without clarity, we need to observe and reason about the current state of the switches (i.e. we need to “read a sign”) — which we sadly can’t do until we turn the lights on.

Two Types of Consistency

When we design products, there are at least two types of consistency we can offer to users — internal and external consistency. Both are interrelated and very valuable, but the latter offers pivotal insight into Framer’s pragmatic approach to design.

Internal Consistency

In the light-switch example, internal consistency describes how all the switches behave within the same house. If “up” is on, no matter which switch in the house you’re using, then the switches in the house have internal consistency. In digital products, we might consider the shape and styling of buttons. 

A digital product might create internal consistency for buttons by always styling them based on these guidelines: 

• Buttons that move the user forward are always blue rectangles

• Buttons that take the user back are always styled as gray text links

• Buttons that cancel in-progress changes, delete saved data, or are otherwise destructive are always red, rounded rectangles

This internal consistency would allow a user to settle into the product with a quick and clear understanding of how to use it.  It may not be pretty, but it will help avoid frustrating confusions — some of which could cause serious problems, like accidentally deleting important data. 

In cases where a product belongs to a larger family of products, internal consistency should usually extend out across the entire brand or company portfolio. In Google’s productivity suite, for example, the toolbars for Sheets, Slides, and Docs were wisely designed to be as consistent as possible across that family of products. And other forms of internal consistency extend beyond that suite, to Google Tasks, Google Analytics, etc. 

This is why design systems become very valuable tools — as a product, team, and company grow. By offering each team and individual team member a shared library of components and styles, teams can easily create internally consistent user experiences, without re-implementing UI elements or needing a meeting to discuss every new bit of UI that’s added to the product. 

Internal consistency is often the focus of discussions around consistency in design. But it’s not the only form of consistency that matters. 

External Consistency

It’s not enough to be internally consistent.  If I ask an electrician to install new light switches across my entire home and find that “up” is the off position for every switch — that is indeed internally consistent. But this would make for a consistently bad user experience (and probably violate local building codes), because internal consistency is not nearly enough. 

Users bring an overwhelming amount of expectations to any product. One expectation we all bring to a modern building is this: when a light switch is up, that switch is on. If we need to remember to invert that expectation for some particular home we enter, that’s externally inconsistent, no matter how internally consistent it may be. 

Some aspects of some products are novel, and users bring fewer expectations to those. But most aspects of most products are fundamentally similar to other popular products — sometimes countless other products. 

Why do we English speakers all expect the cursor to move from left to right as we type into a text box?  It could work differently, where the cursor stays on the right side as we type and new characters, which push the rest of the text to the left. But that would not be externally consistent.  Virtually every text box we’ve ever typed in works in the same fundamental way, so we bring this as a deep (even if unconscious) expectation, to every new product we use. 

Leave a comment

But what if being externally consistent is “worse” than violating the expectations a user will bring to our product?  In that case, we’ve got a tradeoff decision to make. Maybe our product is a tool for professionals in a certain industry, who use the tool 6 hours per day. In that case, it may indeed be worth burdening our users with external inconsistency, because our users will gladly spend a day or two re-learning their expectations — in order to save 2 hours per day, thanks to our innovative design. If instead our product is a wedding-registry platform, where the typical user will only use the product once, we probably can’t justify deviating from the expectations they bring to our product, in the name of “innovation”. 

Our product’s internal consistency must be anchored in external consistency.  

Clarity depends on both. 

Let’s Just “Copy” Figma

So, Framer’s design decision to offer UI layouts and interaction patterns which mimic Figma is an example of excellent design. It’s not an act of laziness, lack of creativity, or optimizing efficiency of the design team at the expense of the user. 

It’s a kind service to Framer’s users. 

Everyone who has previously used Figma will bring expectations to Framer’s product, for how layout and styling should work in a design tool. These pre-existing expectations are informed by their experience using Figma. There are millions of such people, many of whom work hours per day inside Figma. And they don’t want to visit a house where the light switches are all upside-down!

Subscribe now

Hopefully now the text message I received from my designer-friend makes perfect sense: 

Framer’s interface is soooo similar to figma. Easy to use. 

Design is how it works, and clarity is foundational to a well-working design. Consistency is key to clarity, and external consistency meets users where they’re at.  If we get it right, we don’t need to hang signs all over our products. Users won’t think about any of these principles, but they’ll know the product is easy to use.

Share

Have you ever crammed “innovation” into some aspect of your product, where users would have been better served by imitation? I have, but hopefully I’ve learned my lesson and won’t do it again.

Sometimes, imitation is the sincerest form of clarity. 

Sometimes, let’s just “copy”.

Series Preface: For context around the topics and terminology discussed in this series, as well as a bit about me and why I write about them. 

Will your product and organization realize the full business value of decentralized identity technologies, or will the emerging Three-Wallet Problem undermine your investments and efforts? 

Navigating the Rising Tide in Uncharted Waters

In this pivotal installment of the Wallet Strategy Series, let’s build on the foundation previously set and confront the problem head-on. The Three-Wallet Problem is a barrier which, left unchecked, will impede your product’s user acquisition, stifle your potential to benefit from massive network effects, and radically lower the ceiling for growth of all decentralized-IDtech products.

Your role as a product leader or executive is to steer your organization toward success in a market on the brink of a rising tide — one which lifts all boats, including yours. Your long-term potential for growth hinges on the rising tide of decentralized IDtech:

Once our community finds and follows the right path, Metcalfe's Law will quickly create a tipping point, where joining the network is so obviously valuable for each individual and organization that adoption will drive itself. [...] This is the path to wild success for your product or organization, as well as for other pioneers in this space. 

— Wallet Strategy Part 2

As we’ve established earlier in this series, decentralized identity wallets are unlike any digital product of the last two decades because of the unusual strategic dynamics of decentralized networks, and they are the keys to unlocking the vast potential business value in this emerging space. But when misaligned with user expectations, wallets become a closed valve to hold back the rising tide.

Mitigating the Three-Wallet Problem is now critical, as decentralized IDtech finds itself on the cusp of transformative tailwinds for everyone investing in these technologies.  This series will not only make the problem plain but also set the stage for its solution.  As you guide your company through these uncharted waters, understanding and overcoming the Three-Wallet Problem is key to crafting a winning wallet strategy and realizing the full potential of your investments in decentralized IDtech.

The Three-Wallet Problem

As made clear already in this series, applying your great product-strategy instincts in the realm of wallets will backfire for your product and organization. And that’s because the Three-Wallet Problem is unlike any challenge we’ve faced in digital-product strategy during the 21st century. Its implications pose a profound threat, but it’s very simple to understand, if we truly take the full perspective of a user.

The Three-Wallet Problem is this: 

Any given user will develop a strong resistance to decentralized-IDtech products and platforms, by the time she is forced to adopt a third wallet in the course of using such solutions. 

To illustrate this problem, let’s visualize how it manifests for our old pals, Alice and Bob, and then examine the factors that underpin it.

The Last Straw for Alice & Bob

You may recognize these names from diagrams or example scenarios where W3C DIDs and VCs are useful — showing how they can work well to serve users and organizations. But in this simplified illustration, Alice and Bob learn that decentralized-IDtech solutions are actually worse than the forgotten passwords, privacy violations, data breaches, and potential for identity theft they’ve come to expect from legacy digital-identity solutions: 

The Three-Wallet Problem diagram above illustrates Alice’s experience (and Bob’s) engaging with an ecosystem of “decentralized” IDtech solutions, each of which require users to adopt its own bespoke wallet in order to use the given product or platform.  My use of scare quotes around “decentralized” is quite intentional here, to denote that while these products technically use decentralized standards, they are actually de facto-centralized solutions, practically speaking.  

Decentralization is not a function of the technology being used but rather of the network dynamics.  To demonstrate the distinction, the red, dashed, vertical lines in the diagram illustrate the implicit silo created by the tight coupling of each vendor’s product to their own first-party wallet, isolating each product’s silo from those of its peers. 

In this diagram, Alice adopts her first wallet to interact with customer-service departments at certain merchants she patronizes, and she finds it to be an interesting experience. But eventually, she’s surprised to find that her credit union requires her to adopt a different wallet, in order to use the same technologies in their context.  Finally, her university wants her to adopt yet another wallet, in order to receive and manage her education credentials. 

By the time Alice has adopted her third wallet, she feels fed up — and decides she misses the way things used to work. She’s feeling overwhelmed with remembering which wallet to use where and keeping track of how each specific wallet works.  And Bob’s experience with a different set of wallets and products is quite similar. 

Why Three: The Psychological Threshold

But wait, how do we know the number is three?  Couldn’t a user be fed up after the second wallet, or even be willing to adopt five wallets before frustration heightens?  Sure, maybe the number isn’t three. But will a user happily adopt 30 wallets, to facilitate interactions across all industries and use cases?  

Obviously not!  So, to illustrate the principle, we’ll assume the typical user gets fed up after the third wallet. 

Subscribe now

Users Are Already Overwhelmed

Application downloads, onboarding, and authentication for centralized products are already fatiguing users: 

• 62% of installed mobile apps are used less frequently than once per month, and 25% of apps are used only once after installation and then abandoned entirely, according to BuildFire’s statistics.

• 39% of Americans reported experiencing a high level of password fatigue, according to a 2022 study by Beyond Identity.

As cloud and mobile computing have become pervasive, home-screen real estate and mindshare are clearly in short supply among consumers.  User acquisition for any consumer product is already much more challenging than it was a decade ago, and that’s without the added demands that wallets impose on users. 

Wallets Are Worse

Adopting a decentralized identity wallet, one which puts the user in possession of her verifiable data and private keys, is likely to be an even greater burden than the typical app installation and user onboarding.  These wallets require key management, backup, and recovery to be accomplished by the user — in one form or another.  No matter the method used (e.g. social recovery, cloud syncing with traditional authentication patterns, etc.), adopting any such wallet places heightened demands on the user during onboarding, as well as at the time of recovery. And the high stakes of managing keys, whether locally or in the cloud, will heighten the perceived burden undertaken by the user.

Given our statistical understanding of the current state of app fatigue and the new demands that wallets place on users, it should be obvious that each additional wallet which a user is asked to adopt will feel like an even heavier burden than the last. So, it’s now clear that the Three-Wallet Problem will harm users of decentralized IDtech, and stifling widespread adoption will limit the potential for these technologies to benefit society at large.  

Next though, let’s shift our focus to a more central question: How will it impact you and your product? 

Implications for Your Product & Market

To appreciate the gravity of the Three-Wallet Problem for your product and organization, let’s first accept the premise that your product’s growth trajectory will eventually depend on acquiring users who have already adopted other decentralized-IDtech products prior to encountering yours. 

To put the micro-implications of the problem in perspective, consider this: 

What portion of your total addressable market (TAM) do you think you can capture, before you start to run out of first-time wallet adopters?  That is, how long before you’ll encounter users who have already adopted a wallet for some other use case? From then on, the Three-Wallet Problem will create headwinds which make user acquisition progressively more difficult for your product over time — ultimately lowering the ceiling on your potential for growth. 

And for the macro-implications of the problem, we need to contrast expansive networks (interoperable; truly decentralized or federated) vs. restrictive networks (silos; sometimes called “walled gardens”). And we must understand why restrictive networks hold back the tide. 

Let’s start with the macro-implications on the entire space, and then zoom in to unpack the micro-implications for your product specifically.

Macro: Restrictive Networks Prevent the Rising Tide

Play out in your mind the scenario Alice and Bob face in the Three-Wallet Problem diagram, across a global population and countless more products — including those from many other industry verticals and use cases. It’s easy to see that network effects of an expansive network never develop in decentralized IDtech.  Metcalfe's Law never creates a tipping point; and as a result, your investments in decentralized IDtech underperform in the long run.  

This is because the siloed products will onboard their users to a restrictive network.  The size of the network in which your users participate is naturally bounded by your siloed product, and constraining network size will constrain the network’s value.  Metcalfe’s Law still applies, but only to your restrictive network.  The tipping point will never be reached, and the tide will never rise. 

Learning from Email’s Rising Tide

The history of email offers us a clear example, where the prevalence of restrictive networks held back the tide, until an expansive network finally caused the tide to rise. The earliest restrictive networks for email began to form in the 1970s. Many such restrictive networks were formed during the ‘70s and ‘80s, including proprietary commercial email systems like IBM’s PROFS (for PRofessional OFfice System), which was introduced in 1981. The following year, Hewlett-Packard launched HPMAIL, which became the world’s largest selling email system at the time. 

Despite all these efforts and non-trivial adoption across various siloed email platforms, the tide did not rise for email during this era, because restrictive networks hold back the tide. 

However, the expansive network for email began to grow with the adoption of Simple Mail Transfer Protocol (SMTP) for transmitting messages among a diverse set of mail servers, along with other email-related standards (e.g. POP and IMAP, for interoperable client-server connectivity).  These standards allowed any user to adopt her chosen email host, get an email address, and exchange messages with any other user on the expansive network, via her chosen email-client application.  No matter which vendors a given user may have chosen for email hosting and client software — nor which industry or use case inspired her to exchange email messages — she could benefit from the growing value of the expansive network of email users. Many products, many vendors, many applications. But one expansive network. 

Just as Metcalfe’s Law would suggest, a tipping point was reached during the 1990s, as the expansive network grew. By this time, the expansive network for email became large enough — so obviously valuable to its participants — that email adoption began to drive itself.

Thus, the tide began to rise for email. Not because of the standards adopted, but rather thanks to the expansive network their adoption enabled in practice.  And as astonishing as it may seem, the tide is still rising for email’s expansive network, with the number of global email users expected to grow to 4.73B people by 2026, according to Statista.  That’s more than one billion more people using email than in 2017. The tide is still driving massive email adoption in its fourth decade of rising. 

Implications for Decentralized IDtech

The history of email’s rising tide of users is instructive for us now, because it was unleashed by a transition from a myriad of restrictive networks, to a single expansive network. 

The macro-effect of the Three-Wallet Problem is this: When decentralized IDtech vendors build siloed products which require their own bespoke wallet, they each build their own restrictive network (no matter which technical standards they’re using).  And a prevalence of restrictive networks will prevent the rising tide.  

Email took more than two decades to construct an expansive network and see the tide start to rise.  How long can your product and organization afford to wait for the tide to rise in decentralized IDtech? 

Micro: User-Acquisition Headwinds of “Decentralized” Silos

But even without a “rising tide”, you can still build an exceptionally successful product, right?  In many situations, that’s certainly the case — though obviously more challenging. However, the micro-implications of the Three-Wallet problem will make this even more difficult than usual, for decentralized IDtech products. 

Unfortunately, siloed products in decentralized IDtech will not only miss out on the massive network effects of a rising tide.  They’ll also eventually face user-adoption headwinds that we can think of as “silo effects”. The silo effects of the Three-Wallet Problem will cause the TAM for your product to effectively shrink over time, while products like yours face a swell of negative word-of-mouth and bad press. 

Silo Effect: TAM Erosion

In the miniature model presented in the Three-Wallet Problem diagram, we can see that Alice is frustrated and fed up with decentralized IDtech solutions after the third wallet she adopts. She’s then not only uninterested in considering offerings from other firms; she’s actively opposed to them!  Rather than being a user who could be “shared” — easily acquired by the 4th–Nth product or platform — she’s been burned (in more than one sense) and is no longer part of the potential market for other decentralized-IDtech products. 

Many markets are zero-sum: I only need one dishwashing machine, for example. If I buy a General Electric dishwasher, then I won’t buy another from a competing appliance brand.  But with silo effects at play for wallets, the market might be described as “negative-sum”. 

In the Three-Wallet Problem, you’re not just competing with your natural competitors — those products serving your industry or use case, offering an alternative to yours. You’re also competing with every other decentralized IDtech product which requires a user to adopt its own bespoke wallet. It’s a perversely hyper-competitive market dynamic, like if my purchase of a General Electric dishwasher made me unwilling to consider purchasing a Sony television. The two products serve different purposes and should not be competitive in the marketplace, yet thanks to the Three-Wallet Problem, they become so.

In the parlance of Blue Ocean Strategy, this is even more competitive than a red ocean, where the market is well defined and companies try to outperform their rivals to grab market share (i.e. cutthroat competition turns the ocean “bloody red”). We could say that the Three-Wallet Problem creates an “infrared ocean” — where companies must compete across markets and industry boundaries to outperform both their rivals and non-rivals alike in marketing to acquire new users. 

This silo effect means that the addressable market for your product effectively erodes over time, as products in other industries and use cases acquire users. But unfortunately, it gets worse — because the headwinds extend beyond just active wallet users like Alice and Bob.

Silo Effect: Negative Word-of-Mouth & Bad Press

Zooming out a bit, we’ll find that the impact of Alice’s frustration doesn’t stop with her. By her third wallet, Alice has come to resent decentralized identity wallets as a concept.  She’s become a word-of-mouth defender of centralized identity solutions. She’s doing anti-marketing for wallets as a product category and telling her friends and family that your core product was not as good as it first seemed.  

As Alice, Bob, and many more users like them develop and propagate this negative sentiment toward wallets and decentralized IDtech in general, the press will smell headlines and clicks. Discussions on forums and social media will become source material for the tech press to craft stories announcing that decentralized identity is DOA, because DIDs, VCs, and the myriad wallets required to use them are a nightmare for users.

A Problem for Users Is a Problem for You

Does the emergence of the Three-Wallet Problem sound like fertile ground for growing your product?  By the time the problem is manifesting at scale, it will be too late to unwind. 

As experienced product leaders, we’ve likely internalized the wisdom of making customer and user problems our problems. But we typically do this within the scope of our own product. Decentralized identity wallets present a case where we must take a broader view of the emerging landscape and appreciate the problem that users will face across the ecosystem of decentralized IDtech. 

Once you find and adopt a strategy to solve the Three-Wallet Problem for users, you’ll also solve the problem for your product and organization.  The tide can rise, and you can ride it to exceptional growth over the decades to come. 

Solving the Problem & Riding the Tide

Insights from industry pioneers, as highlighted in the IWIB Wallets Report, suggest a future where ecosystems collaborate and interoperate, laying the groundwork for a united front against the Three-Wallet Problem: 

But as some of the ecosystems grow to a critical mass and validate their value creation model, they will start to open up their ecosystems to others, further expanding value creation through cross-ecosystem collaboration, wallet interoperability and customer choice and reach.

In turn, as the value of the cross-ecosystem expansive network increases, the incentive for new participants to join the network will also increase.  And so begins the rising tide.

Leave a comment

Your Wallet Strategy

Now is the opportune moment to reflect: Does your current wallet strategy inadvertently amplify the Three-Wallet Problem? If so, you’re certainly not alone, and it’s only natural for expert product strategists like yourself to initially miss the unusual dynamics at play in the wallets space.

Stay tuned as we unravel strategies that not only mitigate these issues but also harness the full potential of decentralized IDtech’s expansive network. Rest assured, this series will reveal your greatest point of leverage, to turn the tide in your favor. Part 5 will unveil the counterintuitive solution to the Three-Wallet Problem, setting the stage for you to craft a winning wallet strategy in Part 7 — a strategy that unleashes the expansive network's potential for growth. 

Can you envision a scenario where Alice and Bob avoid the Three-Wallet Problem?  If so, you may already be on the path to solving it. 

The tide can rise, and you can ride it to exceptional growth for your product and organization.  The rest of this series will explain how. 

Up Next in Part 4

Having now faced the brutal facts of the Three-Wallet Problem, we need to prepare for its solution — with an unwavering belief that we will prevail in the end.  To set the stage for our solution, we’ll recontextualize the role of wallets in Part 4, to understand why the unconventional strategy needed won’t be entirely unprecedented:

• The Complementary Nature of Wallets: Learn what wallets have in common with tires and guitar strings and understand how your wallet strategy can leverage this dynamic.

• Navigating Wallet Wars: We’ll dissect the impending “wallet wars” and chart a course for the community to avoid mutual destruction for all players in decentralized IDtech.

• Strategic Shift for Success: Let’s set the stage for the solution to the Three-Wallet Problem by understanding the conditions required for the tide to rise, so you can craft your own winning wallet strategy.

Join me in Part 4, as we prepare to unveil the solution to the biggest problem in decentralized IDtech — allowing you to craft a wallet strategy to ride the rising tide, instead of being sunk by it.  Subscribe, reach out with feedback, and share the series to invite more community members to the discussion!

Next in the Wallet Strategy Series:

“Wallet Strategy Part 4: Rethinking the Role of Wallets” [COMING SOON]

💌 Subscribers will get Part 4 as soon as it’s published!

Series Preface: For context around the topics and terminology discussed in this series, as well as a bit about me and why I write about them. 

In Part 1 of this series we established that we share a vision for the rising tide which lifts all boats in decentralized IDtech — your product and organization included. We were also warned of the Three-Wallet Problem, and in Part 3 we’ll explore it in detail, clearly demonstrating why it threatens to prevent the rising tide. And we were introduced to the Wallet-Moat Paradox, which we’ll revisit in Part 6, to understand how it encapsulates both the problem and the solution. 

Now, in Part 2, let's lay a foundation of understanding, to fully appreciate the gravity of the Three-Wallet Problem and the importance of its solution (coming in Part 5).  

We’ll start by reviewing our conventional playbook, and then explore the dynamics of decentralized networks — which have become almost invisible to us, after decades of building products for the Internet. Then, we’ll establish wallets as pivotal for the eventual rising tide of decentralized IDtech.  And finally, we’ll remind ourselves that our experience and skills in conventional product strategy are still crucial to success in this space. 

The Conventional Product-Strategy Playbook

After years of studying the craft of product management, building products, and growing businesses, we have a lot of experience to lean on.  We have theory and frameworks.  We have advice from academics and industry titans. We’ve found things that work and learned from what didn’t.  

Whether we're crafting solutions for fintech SaaS platforms, e-commerce mobile apps, or a box-office system for live events, our approach to addressing product gaps or new challenges has often been clear-cut. Once we understand the shape of a problem or opportunity, solution options typically include “buying”, “borrowing”, or building. We can overlay our corporate strategy and various analytical frameworks to help evaluate these options. And we can lean on intuition, data, and iterative learning to reach our goals. 

Our strategic goals often include controlling the end-to-end user experience, so we can differentiate every aspect of our user journey — and create a defensible moat around our business as a result. There’s nothing better than a highly-defensible moat, right? 

Typically, yes, of course. And why would decentralized identity wallets be any different? 

Well, since decentralized IDtech’s rising tide depends on building a network that reaches beyond your own product and user base, we’re tackling a unique challenge.  The playbook needs to adapt to these unconventional dynamics — specifically in the realm of wallets, where a moat serves only to keep users out, rather than defending against competitors.

And speaking of unconventional, I have a “great” idea!

My Own Horrible Idea vs. Decentralized Dynamics

Succeeding in decentralized IDtech is not just about creating a solution; it's about contributing to and benefiting from a burgeoning, global ecosystem. We need to understand the technology at our disposal and the complex interplay of incentives, human behavior, and market dynamics. Historical examples like the World Wide Web, Email, Bitcoin, and others highlight the critical importance of interoperability and open standards over siloed, proprietary platforms.  

Oh, and by the way, I’m planning to move my writing to a new website which will require you to use the Dan Browser to access it. And since the Dan Browser doesn’t support most Web standards, you can pretty much only use it to access my blog.  

This new bundle strategy will afford many strategic benefits for my blog:

• A delightfully simple user experience, without most of the capabilities browsers typically offer — which aren’t even useful while reading my writing. So streamlined!

• No risk of readers bouncing off my site to follow links or search the Web, so users will only read my writing while browsing. What a moat!

• The app icon and Back button of the Dan Browser can perfectly match my blog’s look and feel. Oh, the branding!

I honestly don’t know why all publications aren’t already making their own single-purpose browsers as well.  Interested in my new browser-and-website product offering?  

If you’re brutally honest, you’ll explain to me that this plan is an obviously horrible idea! What I’m describing involves neither an actual website, nor an actual browser.  This plan would move my writing off of the giant, global, interoperable network that is the Web, and it would make discovery and user adoption radically more difficult.  

This horrible plan of mine would be crushed by the massive network effects of the Web.  My attempt to create a moat for my blog would only serve to ensure that virtually no users ever read my writing. 

The Wallet-Moat Paradox by Analogy

It’s tongue-in-cheek, but this hypothetical “plan” serves as a relatable analogy to better understand the Wallet-Moat Paradox we introduced in Part 1.  In decentralized IDtech, we need to think beyond creating a standalone network. The real power lies in integrating your own product’s atomic network(s) into a larger, interoperable and global network — to both contribute to and ride the rising tide of decentralized IDtech. Failure to do so causes isolation, forcing you to convince each new user to first adopt your wallet, almost like a “website” that forces users to adopt a single-purpose “browser” in order to access it. You’ll benefit from none of the network effects of the broader ecosystem’s growth and will find new users are less and less willing to adopt your stand-alone wallet over time, making it progressively harder to acquire new users for your core product. 

In mature networks, like the Web and Email, it can be hard to recognize these unconventional dynamics. In these mature networks, the dynamics of decentralization are now so profound that they’ve become part of the water we’re swimming in. 

Would you ever consider creating a new email service which can’t exchange messages with Gmail and Outlook users?  Hopefully not, because your “email” service would be crushed by the network effects of interoperable email systems — which together form a single, global network of users.  Any user foolish enough to adopt your siloed “email” service would be cut off from virtually everyone else, unable to benefit from the giant network.  It’s such an obvious non-starter, that it would probably never even cross our minds. 

Over the last 20+ years, we’ve never considered trying to fight these dynamics of decentralization.  So they’re rarely, if ever, made explicit in our product strategy. But these dynamics are as real in decentralized IDtech as they are in mature networks. By trying to row against the current of these dynamics, we’ll eventually be crushed by the massive network effects of the broader decentralized IDtech ecosystem.

Because of these dynamics, the wallets landscape will dictate the long-term success of your product and organization. And we’ll continue to wrestle with the Wallet-Moat Paradox in Part 6, because the rising tide is at stake. 

Wallets and the Rising Tide

We must deeply appreciate why the Three-Wallet Problem (to be outlined in Part 3) is so high-stakes for every person, product, and organization invested in DIDs and VCs.  So, let’s discuss the space as a whole and the role of wallets, highlighting why decentralized identity wallets are pivotal for the rising tide.

The Inevitability and Path-Dependence of Decentralized IDtech

I’ve become convinced that concepts and patterns underpinning decentralized IDtech standards are fundamentally well modeled — optimal for serving individuals and civilization. And on John Siracusa’s "infinite time scale", I suspect that their widespread adoption and ubiquity may be inevitable. 

But reaching that point is path-dependent. 

Decisions and actions we take today will constrain what is possible in the years to come. As we’ll explore together in Part 5, the rising tide will require the gradual bootstrapping of atomic networks and the joining of them into a single network — one that is global and crosses industries, governments, and cultures. 

Once our community finds and follows the right path, Metcalfe's Law will quickly create a tipping point, where joining the network is so obviously valuable for each individual and organization that adoption will drive itself.  

This is the rising tide of decentralized IDtech.  

This is the path to wild success for your product or organization, as well as for other pioneers in this space.  This rising tide will lift all boats.  But when?  

This tipping point may arrive in 3 years — or perhaps it will take 300 years. My sense of desperation for the former has inspired this series, because the wallets landscape will prove pivotal.

The Pivotal Role of Wallets

How soon this tide begins to rise is up to us.  And it will depend largely on how we, as a community, think about wallets. This is the critical factor I’ve so often seen hand-waved or entirely ignored in discussions of usability, user adoption, and product-growth strategy. 

The wallets landscape in decentralized IDtech will act like a valve, either holding back or unleashing the rising tide. 

In concept, decentralized IDtech is not just a new field of technology.  Not just an industry vertical. It’s not like fintech, EdTech, or even DeFi. To be transformational, decentralized IDtech must be one ecosystem — a single global network, on a scale which dwarfs that of any built in the last two decades. 

The history of Uber, Paypal, Etsy, Tinder, and the like have left for us a playbook of sorts, for building centralized networks in specific industries and niches.  But this playbook is only a part of the theory we must understand to build a global, international, interjurisdictional, cross-industry, use case-agnostic network for decentralized IDtech. 

Where traditional theory for network-based business models falls short is in the stitching together of atomic networks. In centralized business models, this happens quite naturally and almost automatically.  A user who first adopted the Uber app in 2011 to order a “black car” in NYC can now share a “shuttle” with other riders to get to the Toronto airport — or even to rent a car to drive while visiting Seattle.  As Uber creates each new atomic network (i.e. critical mass of riders and drivers in a city), Uber’s global network naturally grows.  And the value available to each user of the Uber app naturally grows too, along with the global network.  

Same user profile, same credentials, same app — and each atomic network Uber builds is automatically connected with every other.  Each user can participate in any of Uber’s atomic networks, as a large and unified network of drivers, vehicles, and riders on Uber’s centralized, global platform.

But connecting atomic networks in decentralized IDtech will not be automatic.  The landscape of wallets will determine the size and shape of decentralized IDtech’s global network.  

When will the tide rise?  Will your product and organization ride that tide, or be sunk by it? Answers to those questions will depend on your wallet strategy. 

Realigning Incentives

Some product leaders and executives in the community are already somewhat aligned with the wallets strategy I’ll propose in this series — like some interviewed for Identity Woman in Business's “Wallet Wars or Collaborative Wallet Ecosystems?” (referred to simply as the IWIB wallets report later on in this series).  However, my observation leads me to believe that most do not understand the unusual dynamics in this space, because their chosen tactics imply a self-destructive wallet strategy. 

I’ve seen too many organizations bringing decentralized IDtech products to market and inadvertently setting themselves up for failure. Their strategies, albeit well-intentioned, overlook a fundamental aspect of decentralized IDtech — the role of wallets to serve as a bridge that lets users adopt a product and join the global network, rather than as a moat to keep out competition. This is a critical misstep in harnessing the power of the emerging network.

Quoting from Part 1, I’d like to reiterate a key aspect of this series for emphasis: 

Your long-term success hinges on getting this right, and I’ve aimed here to articulate rationale that centers your product or company’s self-serving interests, not just the success of the broader community and society as a whole.

As you hopefully understood from Part 1, this series will outline a novel problem and paradoxical business dynamic. The typical playbook for product strategy and growth will backfire, if you try to apply it to wallets.  No matter the role that wallets play for your decentralized-IDtech product, service, or business model — nor where you are in your wallet journey — I trust you’ll find relevant and actionable insight by the end of this series, to shape a winning wallet strategy for your own product or organization. 

Subscribe now

While it’s in each company’s best interests to adopt the unconventional strategy I’ll advocate for, I don’t believe there has yet been a sufficient framework and vocabulary to articulate why. I’ll provide exactly that throughout this series.  

But let’s not sell ourselves short. Our experiences and expertise are still crucial assets on this journey. 

Traditional Instincts: Necessary but Not Sufficient

Are traditional product and business instincts still valuable in decentralized IDtech?  Yes, absolutely!  You still need to bootstrap an atomic network(s) by serving a niche use case well and drive adoption on each side of the network (i.e. issuers, holders, and verifiers) to make it viable and self-sustaining.  

And beyond that, your traditional instincts and product-strategy playbook will help you to build a moat around your core product and your business as a whole, through many of the usual means.  

Your years of experience and hard-won instincts for product strategy and execution will serve you well in many aspects of decentralized IDtech. But you will need to find ways to differentiate outside of your users’ wallet experience — rather than attempting to develop, market, and require a bespoke, single-purpose wallet that users must adopt along with your core product. 

Leave a comment

Before we move on to Part 3, does any part of your current wallet strategy sound eerily similar to my own horrible idea?  

If so, you’re not alone, and this series can help. We find ourselves in an unusual moment, where what we know to work well will simply not work.  It’s not obvious, but it’s critical to recognize.  The seemingly inevitable rising tide is path-dependent, and we must chart the right course to get there.  Wallets will prove pivotal, as the valve that unleashes the rising tide. 

Up Next in Part 3

The next installment of the Wallet Strategy Series will be our turning point — as we explore the Three-Wallet Problem and all its implications.  Uncover the biggest problem in decentralized IDtech, and learn why the rising tide is never gonna happen: 

• Alice & Bob Learn the Ugly Truth: We’ll follow Alice’s journey (along with Bob’s) as she learns that data breaches and forgotten passwords may not be the most frustrating problems IDtech can create.

• Decentralized Silos: We’ll learn how to use decentralized technology standards to build traditional, siloed products — just like we could have built a decade ago. Except needlessly more complicated. 

• Preventing the Rising Tide: We’ll discover just how easy it is to stop the rising tide of decentralized IDtech — simply by continuing what we’re already doing.

Join me in Part 3, as we confront the brutal facts, in order to chart a new course, for your product and organization to succeed in the end. I hope you’ll subscribe, reach out with feedback, and share the series to invite more community members to the discussion!

Next in the Wallet Strategy Series:

I’m publishing this series, because we have a big problem in decentralized IDtech.  I call it the Three-Wallet Problem.  Until it’s solved, all other challenges in the space will be of little consequence.

Kim Cameron wrote in May of 2005:

No one is as pivotal to the success of the identity metasystem as the individual who uses it. The system must first of all appeal by means of convenience and simplicity. But to endure, it must earn the user's trust above all.

This is wisdom, and it’s never been more relevant.  We ignore it at our own peril.  

The Three-Wallet Problem will cause your wallet strategy to backfire and jeopardize the long-term viability of your organization. 

It’s already begun to manifest, and it will only get worse.  If the community remains on its current course, this problem will single handedly sink your product or business and prevent the rising tide you’re working so hard to create — and ride to new heights.

But this problem has a solution, and your organization’s wallet strategy will be the key to unlocking it. I hope you’ll find this series valuable in shaping the right wallet strategy, because in some sense, we’re all in the same boat.

Our Shared Vision: The Rising Tide

Since you’re reading this, we likely share a vision for a future where the tide rises and lifts all boats in the process.  The rising tide eventually brings about a ubiquitous identity and trust layer for the Internet, which reaches even as far as in-person interactions in the real world. 

In our shared vision, the proliferation of W3C DIDs and VCs improves enumerable facets of society and daily life.  And this drives exceptional growth for your product and organization, thanks to your long-term bets on these transformational technologies.

I desperately want to see the vision realized.  Don’t you want the same?  Don’t you want the tide to rise in decentralized IDtech and lift all boats, including yours?

But it’s never gonna happen. 

I hate saying so, but it’s true.  And worse still, it’s us — experienced Product people — who are preventing it. We bring our experiences and expertise to the table.  We draw on our past successes building, launching, and growing products. We lean on our hard-won lessons and battle-tested strategic playbook.  As a result, we confidently craft and execute on a wallet strategy that harms our own product and business.  

But that’s only because decentralized identity wallets are fundamentally different from any of our previous products. 

Your Wallet Strategy & Why It Will Sink You

The tide will never rise, as long as we keep trying to treat wallets like the products we’ve had success leading in our careers.  When we try to bring our existing product-strategy playbook into this space and apply it to wallets, experienced Product leaders actively prevent the rising tide. 

• Does your strategy treat your wallet as a key component of your product offering?

• Are you optimizing for your wallet’s user growth and retention?

• Do all your users adopt your wallet as an early phase of your product’s onboarding flow?

• Are you crafting your wallet to perfectly suit your industry vertical, problem domain, product, and feature set? 

• Will your wallet help to differentiate your product to build a strong, defensible moat around your business?

If you answered yes to most or all of these questions, you have great product-strategy instincts. And applying them in the realm of decentralized identity wallets is going to backfire. By the end of this series, you’ll understand exactly why — and how to craft a winning wallet strategy.

Throughout This Series

In this series of eight posts, you’ll gain the unconventional insight you need, to craft a winning wallet strategy and execute on it: 

• Learn why the rising tide is path-dependent and the role of wallets is pivotal.  

• Uncover the Three-Wallet Problem (in Part 3) and understand its implications. 

• Find out why “wallet wars” will ensure mutual destruction for all players in the decentralized IDtech space. 

• Reveal that the rising tide depends not only on the development of atomic networks but also on “safe and open shipping lanes” to connect them. 

And there’s good news! 

The Three-Wallet Problem has a solution — one that can sidestep the problem and bring about the rising tide.  By the end of this series, you’ll not only discover the solution but also craft a playbook for your organization to steer clear of the problem altogether. 

Your long-term success hinges on getting this right, and in this series I aim to articulate rationale that centers your product or company’s self-serving interests, not just the success of the broader community and society as a whole.

The Wallet-Moat Paradox

I’ll conclude this first post in the series by introducing a concept that illustrates the dynamic that accomplished Product leaders don’t yet understand — which causes them to choose the wrong wallet strategy, despite great strategic instincts and the best of intentions. 

I call this unusual strategic dynamic in decentralized IDtech the Wallet-Moat Paradox:

Crafting your wallet strategy to bolster your product’s moat, and keep competition out, will backfire — primarily keeping new users out and enabling competitors to flourish.

Why is this a paradox?  Because building a strong, defensible moat is a wise business strategy to defend our product from competitors. But it doesn’t work in the realm of wallets. By attempting to build a moat with your wallet strategy, you’re isolating your product on an island, separate from the broader ecosystem, rather than riding the rising tide of decentralized IDtech. 

Hidden in the subtext of this paradox are both the problem and the solution. Together, we’ll discover and explore them both in subsequent posts in the series. I hope you’ll join me, because I want your product or company to succeed, alongside other pioneers in the space. 

In Part 2 of this series I’ll share my own horrible plan to move my writing to a new kind of “website”.  My horrible plan will serve as a relatable metaphor to illustrate the dynamics that underpin this paradox.

A Dialogue with Product Leaders and Executives

There’s a lot to cover in this series: the problem, the solution, and the seeming paradox they imply.  I’ll also share actionable advice for avoiding the Three-Wallet Problem, tailored for various wallet journeys, including that of organizations like yours.  As we make our way through these concepts, please bring both an open mind and a critical eye, as I’ll be grateful for your feedback to help me sharpen (or perhaps even invalidate) these arguments.

Leave a comment

I’ll aim to publish one post in this series per week.  If you’re working in decentralized IDtech, I hope you’ll follow along, give me feedback, and share anything that may be useful to your colleagues or broader network.  

To get them as soon as they’re published, you can subscribe for free.

Product Intuition

You do Product in real life, not in theory. I share what I think I've learned from my experience. If you think I'm right, I hope it helps. If not, I hope you'll reach out to set me straight!

By Dan Robertson

Before We Continue

What I’ve outlined above and will cover in this series may be uncomfortable to consider.  In preparation for Part 2, take a moment to contemplate another paradox, longstanding and rigorously-researched advice from Good to Great: 

You must maintain unwavering faith that you can and will prevail in the end, regardless of the difficulties, and at the same time, have the discipline to confront the most brutal facts of your current reality, whatever they might be.

— Jim Collins, The Stockdale Paradox

We will prevail in the end. But on the way, we indeed have some brutal facts to confront.  I hope you’ll join me in striving toward both.

Up Next in Part 2

In the next installment of this Wallet Strategy Series, we’ll delve deeper into the dynamics and challenges of decentralized IDtech:

• Inevitability and Path-Dependence: We’ll explore how the future of decentralized IDtech, though seemingly inevitable, is significantly influenced by the choices we make now. This includes the timing of this technological shift — whether it unfolds over a few years or radically longer.

• Pivotal Role of Wallets: We'll start building a detailed framework and vocabulary to understand why a "moat" strategy for wallets is counterproductive, pushing users away rather than drawing them in.

• Unveiling Decentralized Dynamics: An examination of the inherent characteristics of decentralized networks, contrasting them with the centralized models we're accustomed to, and why a different approach to product strategy is essential.

• Traditional Instincts in a New Light: We'll discuss how traditional business and product strategies remain relevant but require significant adaptation to align with the unique demands of decentralized IDtech.

Join me in Part 2, as we continue to unravel these complex themes, offering insights and strategies for navigating the uncharted waters of decentralized identity wallets. Your engagement and feedback are invaluable as we collectively shape the path forward for the wallets ecosystem.

I hope you’ll subscribe, reach out with feedback, and share the series to invite more community members to the discussion!

Next in the Wallet Strategy Series:

Everyone is welcome to follow along, of course.  But if these posts sound like gibberish, and you’re not curious to learn more, feel free to skip them — no hard feelings at all.  

However, for those of you who already care about these topics, whether you work in Product or not, you probably care a lot about these topics. I’ll assume you, unlike myself at the time of this writing, are working in or adjacent to the field of decentralized identity technologies.

This post will serve as the preface for all future posts in this vein, to spare repeating the same spiel each time. 

The Preface

You’re building a product (or company) in the decentralized-identity space, and I’m not.  You’re already building your boat, and I’m still watching from the shoreline. You probably don’t know me, but I’m rooting for you. I have great respect and admiration for the work you’re doing, so please read my writing in the spirit it’s intended. 

I want to see you, and others like you, find great success alongside one another.  And I believe there’s a path for that, if the community as a whole can create conditions for the proverbial tide to rise and lift all boats. 

It's impossible for me to ignore the approaching potential for a rising tide of standards-based decentralized identity technologies (often called self-sovereign identity or SSI). This tide, I believe, is indeed poised to lift all boats (your product or company included) and fundamentally reshape the way we interact in the digital and physical worlds. But for product leaders, this isn't just another wave to surf; it's a paradigm shift demanding unusual product strategies to suit unusual market dynamics. For you, navigating this tide effectively means not just staying afloat but capitalizing on unprecedented opportunities for innovation and impact in the digital identity space.

About Me

My name is Dan, and for over a decade, I've closely followed the currents of decentralized technologies. My journey has been one of passionate amateur engagement, diving deep into the identity community, learning its intricacies and recognizing the chasm between conventional product instincts and the unique demands of driving widespread decentralized identity adoption. I’ve watched for long enough, and posts that follow are an attempt to contribute to the vibrant discourse in this space. I welcome your feedback — especially your pushback and counterpoints.

For context, I’ve been in product leadership roles at a bootstrapped startup which I co-founded (event ticketing), a Fortune 100 company (e-commerce), and venture-backed startup (fintech).  For a deeper dive into my background and motivations, feel free to connect with me via LinkedIn.

Topics & Terminology Used

If you're already conversant with the world of W3C Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and the transformative potential they hold, I hope you'll find these discussions particularly resonant. For those less familiar, I invite you to explore this exciting space, as its societal and commercial impact will inevitably be profound.  The only question in my mind is when (not if), and the sooner the better. 

In upcoming posts about identity technologies, you can read everything I say through the lens of W3C DIDs and VCs. I'll often refer to terms like “IDtech”, “decentralized IDtech”, and “wallets”. IDtech will refer to the broader field of digital identity technologies, while decentralized IDtech specifically denotes standards and protocols that empower users with control over their digital identities (i.e. DIDs, VCs, DIDComm, etc.), free from trusted third parties mediating interactions. While there are many types of digital wallets, for the purposes of my writing, the term wallets will serve as a shorthand for decentralized identity wallets, specifically.  That is, digital tools that allow users (humans) to manage their digital identities and credentials securely and use them for in-person and digital interactions which leverage decentralized IDtech — which may be expressed as cloud services, mobile/desktop/Web apps, browser plugins, etc.  

What to Expect

As we navigate through these topics, remember that while I present my point of view with conviction (for the sake of clarity), I am open to realizing I have this all wrong or missed some critical aspect. If you think I’ve missed or misunderstood something, please kindly reach out to help me refine my thinking.

While those with “non-business” backgrounds are not the primary audience I’m addressing, perhaps you’ll find concepts and language here to help you better advocate for a strategy you’ve intuitively known is the right approach but haven’t been able to fully explain to your partners from other functions. 

As we dive into the unusual (even counterintuitive) product and growth dynamics in this space, I hope you’ll come to agree that in the realm of decentralized identity wallet development and adoption, all of us can go farther together than any of us on our own.

Why Now?

Since you’ve read this far, I’ll trust you recognize and appreciate the positive impact that decentralized IDtech can have on society — individuals, businesses, and governments alike. I’ll spare you the arguments to this effect and assume we share a vision for a future where decentralized IDtech is ubiquitous.  But in case you have yet to realize this potential, I’ll recommend the book, Self-Sovereign Identity, by Alex Preukschat and Drummond Reed, for an outline of quantitative and qualitative benefits for society that are waiting to be realized, along with in-depth explanations of the technical concepts and standards that can unlock these commercial and societal benefits.  If you are interested in following the space (or trying to catch up), my primary source of current-events coverage is the newsletter, Sovereign Identity Updates, from Identity Woman and Infominer.

With so many amazing voices in this community coming from backgrounds different from my own (e.g. software engineering, public policy, etc.), I’ve had the privilege of learning so much from the community that is far outside my areas of expertise. Hopefully I can start to repay that debt here by offering some relevant insight around product strategy — especially in the realm of wallets — and why conventional wisdom needs to flex a bit, to accelerate rather than impede user adoption for all players in this space. 

Many of the greatest benefits of decentralized IDtech will only be realized as the technology reaches prominence or even approaches ubiquity, which is why the content to follow is absolutely critical. Typical product strategy will not get us where we’re trying to go, and I hope to explain how so, why, and what effective product strategy looks like in this space, especially as it relates to wallets. 

Looking Ahead

I’ll aim to publish one post in this series per week.  If you’re working in decentralized IDtech, I hope you’ll follow along, give me feedback, and share anything that may be useful to your colleagues or broader network.  

If you’re interested in getting them as soon as they’re published, you can subscribe for free.

If you work in Product, you’re hopefully already in the habit of asking “Why?” both early and often. While that’s a critical skill in PM — perhaps one owed its own post at some point — I’ll focus here on doubts and questions in a broader sense. 

My Observations

After nearly two decades working in Product, I’ve worked with a lot of folks. And I’ve been lucky to work with some exceptionally smart people, who are far more effective than the average colleague — and certainly more impactful than I am. While I’ve not kept a spreadsheet to track it, I do think I’ve observed an unexpected pattern among these colleagues which differentiates them from the rest. 

The smartest people I’ve worked with tend to ask the “simplest” questions. While this observation is based in my own experiences, I suspect it may be representative of a broader trend among professionals — and offer insight as to how to learn faster, become more effective at work, and grow professionally. 

The Power of Asking

If you don’t understand something that comes up in a discussion at work, you may be able to get along by just smiling and nodding. How likely it is to work out probably depends on your context. But no matter your situation, isn’t there at least some chance that it will come back to bite you?  And even worse, how much knowledge are you sacrificing to silently pretend you know something you don’t? 

If you don’t know a term or understand a concept being discussed, there are only a few possibilities: 

• You understand it in principle, but are the only one being tripped up by the terminology — and a one sentence clarification would catch you up; 

• You aren’t familiar, but you could benefit from learning about it; 

• You don’t actually need to understand it (typically because it’s a technical concept that your engineering partners have covered for your team); or

• You’re not the only one in the conversation who’s confused.

In any of those scenarios, it’s better to ask than not, in my experience. 

The smartest people I’ve worked with are the ones willing to ask the seemingly most naive questions — because they're not concerned with how they appear in the moment. Over time, they just keep getting smarter because of always asking.

And sometimes the person willing to ask the "simple" question is asking the thing that everyone wanted to ask. Even to the point of revealing that a premise of the discussion is totally invalid, though no one else was willing to question it, for fear of seeming like they didn't know what everyone else knew.

I learned this lesson as a young musician, growing up in the days before a Web search could offer a great explanation for any topic or concept. As soon as you pretend you know something you don't, you've backed yourself into a corner where you can't ever ask about it later (without looking like a liar). I once silently implied that I understood what a friend meant by “the third” and “the fifth” when describing how to play a song — and didn’t learn this valuable musical concept until years later.  In hindsight, I could have taken a multi-year shortcut by simply admitting, “Oh, I’m not familiar with that. Is it easy to explain?”  Instead, I pretended to know more than I did, to seem impressive. I prioritized seeming smart over becoming smart. Lesson learned!

When pondering the cause of this correlation, I think there’s two plausible explanations.  Either: 

1. People who already know a lot have earned a sense of confidence in their body of knowledge, which allows them to feel safe to ask a seemingly naive question; or,

2. People who have a personal policy of always asking questions when they don’t understand something (whether because of a deliberate strategy or natural curiosity) gain more knowledge than others over time.

I have no data to justify either of these, but my gut says the latter is the more likely explanation.  That’s because of my personal experience running my own N-of-1 experiment. 

Once I started to notice this pattern, I started to intentionally ask more questions when I felt like I was the only one not understanding the discussion.  When I did so, I found the following results: 

• I did indeed learn faster, by internalizing new concepts that would have otherwise flown over my head — even if some of them took some offline follow-up on my part (e.g. reading more after the meeting, watching an explainer video on YouTube, etc.).

• Sometimes I was the only person in the conversation who was willing to ask a clarifying question about some implicit premise, and it turned out to not withstand even the slightest interrogation. 

I recall one instance where the person who called a meeting had spent a few minutes introducing the topic of a discussion about “Omni-channel Commerce” — and I didn’t understand what was “Omni-channel” about the discussion, given everything else the meeting organizer had mentioned in the preamble.  I simply asked, “Sorry, I’m probably missing something, but how is this involved with the work for the Omni-channel Program?”

Much like I’d observed at times, when folks smarter than me would ask the “simple” question, the meeting organizer’s answer was, “Oh, sorry, I should have said ‘Source-aware Inventory’.  I just misspoke.  It’s got nothing to do with the Omni-channel Program.”  And the rest of the room joined me in a collective chorus of, “Aaaaaah…”. In this case, the “simple” question turned out to be quite apt.  Then we were able to have the conversation with everyone on the same page about the scope of the subject matter.

Developing a Playbook

Since then, I’ve developed the following playbook for myself, to maximize my opportunities to learn on the job: 

1. Never pretend you understand something you don’t!

2. You don’t need to stop every meeting about everything anyone says that you don’t understand, but if you’re being asked a question about something you don’t understand, you should not try to fake an answer. “I don’t know, but I’ll figure it out and report back” is always an option, and it’s radically more productive than just trying to guess or make things up. 

3. You can quickly search the Web for a term/concept you’re wondering about, to figure out whether it’s something you can read up on by yourself or you’ll need help from a team member to understand (e.g. some terms and concepts will be unique to your company, team, codebase, etc.).

4. It’s totally fine to interject with something like, “I am not familiar with X [or don’t understand X fully]. Is it easy to explain now — or should I read up on that, or connect with someone later, to learn about that?”

5. Keep a running list of things you’re not sure about, so you can do your own research when you have time and ask teammates about the things you couldn’t understand on your own. 

6. Get to know anyone who you notice asking the “simple” questions in work discussions. They may be an especially smart and effective teammate — or on their way to becoming one. It’s a big signal that someone may bring a high level of both character and competence to your team or organization. 

Subscribe now

For me, these strategies are more critical when I’ve joined a new company or team, or have taken on new scope in my role.  Still, even after years on the same team and product, the not-knowing-things phenomenon may happen less frequently but never entirely stops.

The great news is, I’ve found that experts tend to enjoy sharing what they know. If someone is put off by you asking about a term or concept, either you are asking something that you could have gotten an answer to on the first page of Google results, or that person is somewhat of a jerk — or perhaps they’re a good teammate having a hard day, which happens to the best of us.  If someone’s frustration about being asked turns out to be a pattern, just try to find someone else who seems to know things and is happier to help.  

Share

As a kind engineer (now a friend) once told me, when I apologized for asking a lot of questions, “No need to apologize. We all need to get up to speed!”

The next time you’re assuming you’re the only one in the conversation who’s confused or not totally following, take a moment to look up an explanation. If clarification is not readily available, asking the simple question could be your chance to learn something new, or it might just be the question everyone else was too scared to ask for themselves.

During my years in Product at both a Fortune-100 company as well as startups, I’ve had a full spectrum of experiences in this regard — from wondering how to tactfully put an end to recurring 1:1s that were unproductive, to wishing I’d done a 1:1 with a colleague months earlier. 

As always, the right thing for you to do will depend on your context.  But in general, I’ve found that the rule of thumb for successful 1:1s is this: 

Early, not often.

The When

I always try to get a 1:1 scheduled with everyone I’ll be working with in my role, as early as possible. If I’m joining a new team, my first order of business is to compile a running list of colleagues I need to meet and kick off a working relationship with.  At some point in the first couple weeks, I’ll aim to find 20 minutes on the calendar to meet with each of them — my immediate partners (engineers, designers, etc.), my peers in Product, and any other partners and stakeholders I think I’m likely to be working with on any frequency.

When someone new joins the company or moves to a team that I work with regularly, I aim to do the same with them. 

And for the majority of my colleagues, that first 1:1 may be our last.  My default is to not set up recurring 1:1s, except in cases where it’s obviously productive.  This typically includes 1–2 key partners from each function — folks who I will be collaborating with often.  This may be a lead/principal engineer or engineering manager, a designer or design lead/manager, my Product peer from any other team whose work needs to stay in sync with mine, etc.

For everyone else, I won’t set up a recurring 1:1, unless I find some compelling cause to make it a regular thing. But I will absolutely meet with them once, as soon after I/they join the team as is practical.

There is a ton of value in an initial 1:1 with any partner or stakeholder, and the sooner the better — as I’ll explain later. But it’s much better to add an ad hoc meeting to the calendar when there’s something important to discuss, than to keep a recurring session on the calendar just in case. Just-in-case standing meetings often become mostly wasted time.  That’s true for almost all colleagues, except for those that are the most critical partners for my product or area. 

The Why

In general, the first 1:1 breaks the ice.  When you need to contact them to ask a question or see them in a meeting, it won’t be awkward, because you’re already acquainted.  It’s never easier to break the ice than the first couple weeks that one of you is in your role. And it’s also the perfect time to set the tone for the relationship.  

My goals for the first 1:1 with each colleague are these: 

• Make sure they know that I'm not a jerk and am here to help

• Make sure they'll feel safe collaborating with me

• Make sure that our first 1:1 conversation isn't when some issue or conflict arises — so we'll have some relational capital to help when it does

For the last of those goals to resonate, you need to keep in mind that hard situations at work will inevitably come, tensions will inevitably rise, and there will eventually be some form of conflict with someone(s).  

If you’ve never really had 1:1 time with someone during peacetime, it’s hard to try to build a functional relationship with someone on the fly, once you’re facing wartime.  So, the last thing I want is for our first 1:1 conversation to be me needing to inform them of some crisis or apologize for a mistake I’ve made.  That’s a hard way to introduce yourself!

1:1s don’t need to feel “productive” to be a great investment of your work time. I think Stephen Covey was the first to advise that when it comes to people, slow is fast, and fast is slow. This is so true and so important — in all areas of life. 

Relationships outside of work help to illustrate the validity of this advice. If I only talk to my kids when there is family or household business to discuss, it’s going to be painful every time I tell them they need to get to bed or turn off the TV. I have to build and maintain a healthy relationship with them interpersonally, if I want to earn the right to bring them news they don’t like. Otherwise, I’ll be seen as the annoying stranger who does nothing but break up the fun!

And the same is true for someone I work with: if the only time they hear from me is when I tell them we have a problem or an urgent deadline, I’ll feel to them like a harmful intruder in their life — but if we have good will built up already, they’ll feel like we are on the same team, facing a shared challenge.

The How

During my initial 1:1 with each new colleague, I do general get-to-know-you stuff, like asking how long they've been at the company, on the team, etc. I’ll ask about what they do for fun, where they grew up, or whatever else happens to come up.  It’s useful for our working relationship to build a personal rapport in this way, and there’s always a chance of finding a genuine friend at work. 

I met two of my best friends in my initial 1:1 with each of them, when I joined their team, and we’ve remained close for years after we stopped working together — so there’s always some possibility that the new connection goes beyond just fostering an effective working relationship. 

During the initial 1:1, I also focus on level-setting on the following points, to prepare us for an effective working relationship:

1. Valuing Their Expertise: I acknowledge their unique skills and expertise, emphasizing my appreciation for their input. This is tailored to their role, highlighting that I welcome thoughts and feedback on a broad range of topics, even those outside their typical scope. This is particularly relevant when engaging with engineers and designers.

2. Encouraging Open Feedback: I stress the importance of their feedback in shaping my work. Quick and direct feedback is crucial for me to learn and adapt. I assure them that all feedback is welcomed and will be received positively.

3. Gathering Contextual Insights: Understanding the broader context of the product and team is invaluable. I ask for any insights into the organization's culture and ways of working, to help me integrate effectively and discern how I can best be effective in this context.

4. Supporting Their Role and the Team: I inquire about how I can best support them and the team, especially from their perspective. This is an opportunity for forward-looking collaboration, particularly if I'm new to the team or if they are joining my existing team.

5. Cross-Functional Product Insight: For designers and engineers, I clarify my role in decision-making on the Product side. While I may make the final calls, collaboration and collective input are key. I explain why I’ll rarely use the term "requirements"; instead, I’ll focus on collaboratively determining the best project scope and shape of features. My approach involves valuing their input and being open to discussions — even pushback — on project plans, to ensure that we collectively build the best product we can.

Subscribe now

If you want to keep some cadence of 1:1s with colleagues who are not critical to stay close with for work you’re collaborating on, Donut bot for Slack and MS Teams (or any way to accomplish the same effect) is nice for setting up less frequent 1:1s with team members or folks from the broader org, to give the less-work-focused face time with various folks. Donut allows you to schedule a single 1:1 each week, and it will handle pairing you up with one of the colleagues who have opted in.  Rather than a weekly or monthly recurring meeting with each person, you’ll be matched with one person each week — which is a much more manageable time commitment (though you can opt out on any given week) and still gives a chance for some time to meet colleagues and socialize.  I’ve found it especially useful in a remote-work environment, where there’s no opportunity to bump into coworkers in the kitchen or as you pass their desk on your way back from lunch.  

Impactful 1:1s with Partners & Stakeholders

I think people enjoy working with folks they feel like they know and have a decent relationship with (not full-on friends in all cases, but friendly and acquainted).  When it comes to non-manager 1:1s, a little goes a long way, and the earlier the better: early, not often. Get off on the right foot, set the right tone for the relationship, and be ready for whatever comes up in the future. 

Share

I’ve shared my own list of goals and points I want to communicate to my colleagues early on, but it may not be the right fit for you.  What goals do you have for your first 1:1 with colleagues? 

Whatever they are, accomplish them early, and you’ll be glad you did.

In PM communities online, I’ve seen a lot of variations on the same question:

How do I say no to a feature request from [some particular stakeholder]?

The best way I’ve found to say no to stakeholders is to instead say maybe.  

But this is not a passive response that kicks the can down the road, amplifying the eventual disappointment and frustration the stakeholder will experience when you finally tell them no. Instead, it’s a structured and rigorous “maybe” — which explains what it would take for the maybe to become a yes.  And it’s an offer to partner with the stakeholder, to work toward a yes.

How to Say Maybe

You already have ways of deciding what to build and prioritizing the work. You probably don’t make roadmap decisions based on your mood or rolling dice.  The right way to make roadmap decisions varies by context; like almost everything in PM, it depends.  But your organization probably has certain norms about how value is estimated and work is prioritized. And you probably add on your own judgment and considerations about your specific product and its role in your company’s strategy.  

Telling a stakeholder “maybe” involves giving visibility to your process for prioritization and roadmapping.  It may even involve explaining how software development works, how teams within your organization depend on each other to coordinate effort and deliver larger pieces of value for the business, and how inefficient it is to constantly shuffle the roadmap, abandon in-progress work, and allow team morale to wane as a result. 

It’s not just saying “maybe”.  Instead, it’s saying “Maybe, but in order to prioritize the feature you’re asking for, we would need to convince ourselves that it’s valuable enough to adjust the team’s existing roadmap and make room for it.”

I’ve found great success by saying or writing something like this in response to feature requests from stakeholders:

Thanks for suggesting this! I’d love to work with you to try to build a business case to get this onto the roadmap. We’ve already got our roadmap filled in for the next N months/quarters, but it’s certainly possible to make tradeoffs, if the business case is strong enough to displace existing commitments. We’ll just need to be able to quantify the value of this work, so we can show why it’s more important than other planned work. Do you have a sense of how we can quantify the value in terms of increased revenue, increased customer retention, lower customer acquisition costs, savings in labor costs, etc.? And where we can find data to build a model to arrive at that $ value?

The implicit subtext is this:  “I want to help you on this and appreciate you, but we’re both going to have to do work to justify this. And the ball is now in your court.”

When to Say No (or Yes)

This was my go-to response for a few years at a past company, a Fortune-100 enterprise, to out-of-band feature requests (i.e. coming from some stakeholder, and not obviously important to prioritize, given the product direction at the time). The most common outcome was that I never heard from them again about that request.

Most of the time, I never had to give an explicit no, because the stakeholder who made the request arrived at “no” on their own.  They knew that there was no real case to be made for displacing work already on the roadmap, in order to turn the “maybe” into a “yes” — so they arrived at “no” without me needing to be the one to say it. 

If the stakeholder is optimistic that there’s a strong enough business case to be built to prioritize the work they’re asking my team to do, then I’m happy to engage and help with that.  If I’m also optimistic that it’s very valuable work, then I’ll even do most or all of the leg work myself. But if I’m not yet seeing their vision, the more skeptical I am, the more I’ll delegate the legwork to them.  And I may become more convinced as we make progress — in which case I’ll stop delegating and start to drive it forward on my own as much as possible. 

If we end up working to build a business case, at some point the decision should become obvious to both of us.  If at some point we’ve both lost interest, it’s another implicit “no”.  

If and when the “return” of the in-draft business case starts to look strong, then I will work with my team to estimate the “investment” side of the equation — the development effort, impact on infrastructure costs, tech-debt implications, etc. — to round out our business case and provide a sense of ROI to inform the final decision. In our decision-making process, we need to also weigh the estimated effort against the anticipated value, to understand the expected return on investment (ROI). Considering ROI enables us to see beyond immediate benefits and consider short-term costs and long-term implications. 

If we complete the work to estimate the quantified value of the work and the cost of unlocking it — then it’s an easy decision for us both to agree on:

• YES — “Yes, let’s build this (Feature X) next quarter instead of Feature Y, because X is expected to drive 40% greater annualized revenue lift than Y would!”

• NO — “No, this (Feature X) won’t be as valuable as Features Y and Z that are occupying our roadmap for the rest of this year. Here’s our current roadmap, if you want to click the links under each item to see the business case that’s driving each of those, for comparison’s sake.  But I’ll keep it in the bullpen for when we start planning next year, to see if it would make sense to do this work then!”

Educating Stakeholders

For the eventual yes or no to make sense, you may need to help the stakeholder understand aspects of the situation that they’re entirely unaware of, even if they feel obvious to you.  

Changing your team’s roadmap with little or no notice can feel chaotic and frustrating for some teams, and that’s a very real cost for your company that needs to be considered.  Changing your team’s roadmap may also have implications for other teams who are doing work that depends on yours, meaning that disrupting your team’s roadmap may disrupt other teams and cause frustration, if not waste work that has already been done toward upcoming deliverables. And there may be other factors on your mind as well, which you’ll need to help the stakeholder understand and appreciate, so they can understand your eventual roadmap decision about their request.

An Easy “No”

An example I recall from my own career, where someone made a request for a change that had no real justification, was at a large, global e-commerce company I worked for. Someone from the Gift Card Ops team wanted work done to enable a special, new kind of gift-card promotional campaign in their specific geographic business unit (one of several geographies my platform supported). The folks asking for it wanted it because it was going to move the needle for their KPIs, purely around the gift card program in their geography, but it paled in comparison to the global features my team was already planning for the next year — which would drive much higher revenue lift or keep us compliant with regulatory changes (i.e. allow us to keep operating our business in the EU). It wasn’t like it was a waste of time, but the opportunity cost of doing what they wanted would have been way too high.

Subscribe now

When I gave this stakeholder a structured, rigorous “maybe” — she thanked me and then never mentioned it again. I never needed to tell her no, because she arrived at the answer herself.  And we continued to have a very positive and collaborative working relationship going forward, as a result. 

An Eventual “Yes”

I also recall a counterexample from my career, where our CEO and primary salesperson suggested that we build a pivot-table functionality into our data-analysis product.  He explained that he’d used our existing export functionality to pull various reports and build such a pivot table in Excel, to show a current sales prospect when he presented their proof-of-concept (POC) implementation of our product.  Rather than saying yes or no, I asked if he could continue making these spreadsheet files, one for each sales prospect we presented a POC to, and we would add a “Download Pivot Table” button into the product, which would allow the user to download the manually-created Excel workbook as a static file. I explained that this Wizard-of-Oz experiment would allow us to gauge the value such a feature would offer before spending time to build it into the product. 

Our CEO agreed, and within a month of presenting these manually-built Excel pivot tables, it became obvious what a valuable feature it would be to build — and we had learned how it could be refined to work better for our users, based on feedback from sales prospects who had been shown or had used the Excel pivot table we provided. 

The result was an obvious and unanimous “yes” to a very well understood scope of work that we were able to confidently and quickly deliver as a native feature of our product, to great success going forward.

The Results

Either way the decision goes, it’s not so much me who is saying no (or yes). Instead, it’s the reality of what’s best for my product and our business as a whole (which we both clearly share an understanding of), which is resulting in a “no” to the feature request.  The stakeholder may feel frustrated, but by this point the frustration won’t be with me as the PM.  I was the PM who was game to help make it happen, if it made sense for our business!  

And if this feature request was among the many that are obviously not valuable enough to find a place on the roadmap, the stakeholder will likely not come back with another feature request, until she has one that she thinks is actually valuable enough to the business as a whole, to actually be worth building the business case. 

Share

If you’re trying to figure out how to say no to a stakeholder, is there a way to frame a structured and rigorous “maybe” instead?

The key has been learning to ignore (at first) most of the advice I found in business books and personal-growth content during my 20s. 

When I’m feeling stuck in a frustrating or unsatisfying circumstance, I don’t need to start with "Why" or begin with the end in mind. That’s great advice for most situations, but when I’m feeling stuck, I don’t need a grand plan for getting where I want to go. 

I don’t even need to know where exactly I want to go. There’s only one thing I need, when I’m feeling stuck. 

I need traction. 

Until I have traction, nothing else really matters. And trying to plot a course, when I can’t even control if or where I’m moving, is a distraction (we could pronounce it as “dis-traction” in this case) at best.  At worst, it’s demoralizing and unmotivating. 

The Four Phases

After managing to get unstuck in various aspects of my life over the last decade, I’ve started to identify an implicit framework — the four phases that have gotten me unstuck and onto a path to where I’d rather be. And it always starts with traction.

When I start to feel stuck, the four phases of getting myself from here to there are these:

1. Traction

2. Target

3. Trajectory

4. Time

I’ll explain them all, and perhaps the last three will sound like familiar or common-sense advice. But those phases can’t help you when you’re truly feeling stuck, because being stuck is as much a psychological state as a practical one.

When I’m feeling stuck, I’ve become insecure and unmotivated.  You only really feel stuck once you’ve tried to improve things, to no avail. Until you regain your sense of traction, you can’t sustain the confidence and motivation it will take to execute on a plan. And having a grand plan will only serve to highlight your lack of traction.

So, I’ll explain all four phases, but I’ll start where I always start when I start to feel stuck. 

1. TRACTION

If your car tires are spinning in the snow, that’s the only thing to worry about.  Maybe you need to replace your tires or buy some snow-chains or trade in your car for a 4-wheel drive vehicle. But however you manage to do it, your singular focus must be finding a way to get traction.  You’re not going anywhere until you have it.  

When you don’t have traction in some aspect of your life, it feels like playing a video game with a faulty controller — one that has a drift in the thumb-stick and an A-button that sticks.  If you’re playing a video game with a malfunctioning controller, advice for how to play the game is useless and frustrating. The only advice you need is to repair or replace the controller. 

What traction looks like when I’m feeling stuck has varied based on the context.  As with most things, it depends. But here are some examples: 

• 30 minutes per day for 4–5 days per week spent learning Javascript gave me traction in my career, when I found myself managing a product aimed at developers.

• Paying off debts from smallest balance to largest balance was what gave me a sense of traction in my personal finances, when it felt like I couldn’t make progress.

• Doing a 4-minute routine of bodyweight exercises every morning gave me traction, when I felt stuck in a poor state of physical fitness. 

What all of these have in common, though it may not be obvious when reading the list, was how small these efforts were and how modest the progress was. I learned Javascript (you still don’t want to deploy any code I’ve written to Production though!) in relatively short bursts a few days a week for about 6 months. I paid off my smallest debt (a $500 balance, out of almost $300K in total debts) within the first month of really trying. And my 4-minute exercise routine took approximately — and you’re not gonna believe this — 4 minutes each morning. 

Traction can start very small, because it compounds. It unlocks confidence and motivation, which leads me toward larger and more strategic moves.  When I start to see that I can make intentional progress in the area where I felt stuck, I no longer feel stuck. Even if the progress is tiny, it’s progress.  I attempted to make some specific progress, and then I actually made that progress. I’ve found something that’s working, which reignites my belief that I’m capable of more progress.

When I’m feeling stuck, my only objective is to get some traction — any traction at all — and then build on that. 

2. TARGET

Once I have gained a sense of traction, proving to myself that I’ve managed to intentionally move in a direction, then it’s time to start thinking about setting a target.  If I can make intentional progress in a direction of my choosing, it’s now great advice to start with “Why” and begin with the end in mind. Coupled with my sense of traction (i.e. earned confidence), identifying a destination I’m excited to get to will be even more motivating.

I think most folks would put Target (or Vision, Objective, Plan, Goal, etc.) first in the list, but I don’t agree.  Until I’ve won a sense of traction in a given domain, it’s unhelpful to think about where I’m trying to go. It only serves to demoralize me for my lack of progress.   But once I can demonstrate to myself that I can intentionally create even modest movement in a direction of my choosing, it is useful and productive to pick a destination I want to aim for.   

In physical fitness, perhaps it’s to squat a certain amount of weight in the gym or finish a half marathon. In personal finances, perhaps it’s to buy a house or have a certain net worth by some future date.  Professionally, perhaps it’s to work at a specific company (or found a company), earn a certain income, work on a certain kind of product, or achieve some level of leadership.  If the target is a very long-term one, I’ll probably break it down into milestones I can track toward. I’ll outline a plausible plan to get there. 

Once traction is gained, setting a target gives direction. It's expected that plans evolve and targets shift as life unfolds.  As long as I still have traction, I’m free to choose a different target and plot a new course, whenever I decide that’s the best fit for me. 

3. TRAJECTORY

Once I have traction and set a target, I begin to monitor my trajectory toward that target.  I can plot my annual income on a graph to see how fast it’s growing. I can track how many push-ups I do each day, to make sure the number is increasing as the weeks pass. Or I can create a monthly calendar appointment with myself to evaluate my recent progress and gut-check how I feel about my pace of progress, based on more qualitative measures. 

Monitoring my trajectory helps me decide if I need to make adjustments in my day-to-day — seeking out advice, learning new skills, focusing effort on certain activities, meeting specific kinds of people, working or practicing more hours per week, looking for a different job, working on side projects, etc. 

How quantitative I am about monitoring trajectory depends on the area of my life I’m concerned with and how quantifiable my target is. Financial targets are pretty easy to quantify and so is the trajectory toward the target.  Learning a musical instrument is less so, but perhaps I’d count the number of songs I’ve learned to play perfectly or the average time it takes me to learn a new song.  If the area of concern is my marriage or my relationship with one of my kids, that will probably be pretty hard to quantify; but even then I should have a pretty good subjective sense of the progress being made, if I take time to think about it.

Returning to the metaphor, if I’ve got 1K more miles until I reach my target destination, and my trajectory (i.e. pace) is 50 miles per hour, I’ve got an estimated 20 more hours of travel ahead of me. If that pace starts to slow down, I can decide whether I want it to speed back up and figure out what to change to accomplish that. If I decide 20 more hours of travel is too long, I can explore options to accelerate, to improve my trajectory.

4. TIME

Time is really just a one-word way of saying “Keep going!”  Once I’ve got traction, have chosen a target, and am monitoring my trajectory — time does the rest. Time is absolutely critical, because pretty much any satisfying accomplishment is going take time.  In fact, it’s the effort invested over time that makes an accomplishment satisfying. 

Results tend to compound as the calendar pages turn, if I “keep my foot on the gas” consistently. Most of us are very familiar with this concept in the realm of compounding investment returns.  Your trajectory toward your target balance will speed itself up over time, even if you don’t save more per month over time.  The gains will compound. I find that the same is true for my investments in skills, knowledge, and strategy.  Once my trajectory is good, even if it’s modest, time is very much my friend. 

If I overlook the role of time in making progress, I get discouraged very easily. I’ve not yet reached my target, so ignoring time’s role can easily fool me into believing I’ve failed. But when I consider time to be an explicit phase of the process, I’m able to be encouraged by progress and keep going. If you’re heading in the right direction at a good pace, that’s really all that’s left to do — keep going! 

The Long Game

In all of this, I try to keep some perspective on my personal timeline. Even at 40 years old, it’s reasonable to think I’ve got a lot of time to keep growing and progressing in all areas of my life possibly into my 60s or even 70s, barring bad luck in terms of health problems.  I’ve had to learn to ignore the outlier stories of people rising to be executives by X years old, unicorn founders becoming billionaires in their 20s, and all the “30 under 30” lists.  

As Product people, we’re extremely fortunate to get to peak late in our professional life. Unlike NFL football players, who probably need to find an entirely new career by the time they reach their late 20s, we can keep growing and improving professionally until a relatively late stage of life. That means that career and financial targets can have a very long timeline and still be achieved, if we maintain our traction and trajectory toward those targets. 

Subscribe now

There’s time to adjust as we go, and struggling now is preparation for success later — even if that success comes in a different field. And since the game is a long one, I can always step back up the list of four phases, whenever something isn’t working how I’d like: 

• This is going to take too long (i.e. time).  How do I adjust my trajectory to fix that?

• I’m struggling to keep my trajectory where I’d like — perhaps for lack of motivation.  Is this still a target I’m interested in pursuing, or should I consider targeting a different destination to head toward?

• This target is no longer appealing or seems unrealistic now.  What area do I need more traction in, to make this target achievable or to support a target I’m now more interested in? 

Enjoying the Struggle & Progress

I think enjoyment — finding joy and satisfaction — is a skill of its own.  If I can’t enjoy the struggle of finding traction and find satisfaction in monitoring my trajectory over time, I won’t be able to truly enjoy the eventual destination I’ve been trying to reach.  There’s no circumstance or achievement out ahead of me that will force joy or satisfaction upon me.

I try like hell to practice those skills now, as I pursue the future I want.  That way, by the time I finally get where I was trying to go, I can enjoy that as the next satisfying experience in a long line of them. 

Feeling stuck right now?  If so, what might give you a sense of traction, no matter how small it might be? And what joy can you find in the middle of this struggle? Remember that our struggling moments can become our fondest memories, once we eventually make our way from where we were stuck to where we wanted to be. 

Share

Start with traction, don’t forget to let time do its thing, and it’s totally up to you when you want to start enjoying all of it.

We can have anything we want, but we can’t have everything we want. And pretty much nothing we want will come for free. Finding the right set of scope for a project, that considers all aspects and implications and maximizes return on investment (ROI) — that’s the magic.

Since almost everything about a project is negotiable, that must mean that Product is negotiating against the rest of the team, trying to get as much as possible from them for the lowest possible effort estimate?  I’m sympathetic to that question, because I know firsthand that it can sometimes feel that way.  But no, absolutely not. 

Your True Adversary Isn’t Your Teammate

So, let's set the record straight: the true negotiation is not within our team. The actual negotiation is against a formidable, silent adversary known as Reality.

Reality is always willing to negotiate and will “accept” any number of “offers”.  But he won’t give you everything you want — as frameworks like the project management triangle, CAP theorem, and Zooko’s triangle illustrate in their respective domains. And what Reality is willing to give you is going to cost you something.  That cost may be in the form of your team’s time and effort, complication of your product’s UX, tech debt, delayed timelines, opportunity costs, etc.  Every time you try to reduce one kind of cost, you typically pay more cost of another kind.  

We often fall into the trap of viewing our team members in Design or Engineering as the opposition during negotiations of scope, timelines, and other tradeoffs. This adversarial dynamic leads to a tug-of-war over how much can be done and how fast. However, the real negotiation isn't with our colleagues—it's with Reality.

Reality is that stern negotiator with a poker face who watches as we lay out our plans and resources, only revealing the outcome once we've committed. It's not until we're deep into development that we discover if we’ll actually be getting what we wanted for the price we expected to pay.

You vs. Reality

When you, as the Product person on the team, make an offer that you think is a win for your team and product, Reality will silently allow you to proceed. If your offer underestimated the costs Reality demands for your desired outcome, he won’t bother to mention it, rather simply let you discover that on your own, eventually. If the outcome you want isn’t possible, he’ll let you invest time and resources into executing the “deal” — only to reveal it’s a no-go once you’ve already sunk your resources into the failed endeavor.  And even if the deal works as planned, he’ll never speak up to let you know if he was open to an even more favorable, higher-ROI deal you hadn’t thought of. 

To illustrate with an example, consider this: you offer three weeks of your team’s time for a feature you believe will be a game-changer. Yet, what you don't see — and what Reality knows — is the domino effect of backend refactoring and the downstream consequences on user experience, which result from executing against your well-meaning “requirements”.

So, you've negotiated against Reality, offering weeks of effort for a feature that, unbeknownst to you, will come at a greater cost than you anticipated and won't resonate with users as expected. Reality knows this and silently lets you proceed with your plan, well aware that you're making a much worse bargain than you meant to.

But it doesn’t have to be a losing battle. The trick is not to outwit or outmaneuver Reality but to approach the negotiation with a wealth of collective knowledge, experience, and creativity. This is where your team comes in.

Bring Your Team to the Same Side of the Table

By uniting as a team in crafting the deal, we can face Reality with more information and creative options. With our combined expertise, we're better equipped to predict outcomes, understand implications, and construct deals that get us more of what we want for less cost — and ones that Reality is more likely to accept. This united front changes the dynamics of negotiation from a solo struggle to a team effort, from an almost-certain defeat to a likely win.

Across the negotiation table, Reality represents a host of factors: the calendar, your budget, team capabilities, tech stack limitations, and more. Recognizing Reality's role and facing it as a team is how we transform negotiation from a gamble into a strategic decision.

Even if it’s felt tense to negotiate scope and project plans with your team in the past, they were fundamentally only trying to help you understand the constraints that Reality was going to impose on the deal.  The mood shifts when you stop resenting them for it and appreciate it as the help that it truly is, as you work to win the negotiation against Reality. When we negotiate as a team, we aren't just guessing at what Reality might accept. We're leveraging our collective strength to shape a winning deal that Reality will cosign. 

Subscribe now

So, the next time you're planning a project, remember that your entire team is on the same side of the table. Invite their questions, input, and even pushback.  Ask them why exactly X won’t work as well as you thought.  Ask them if Y may work better than X, or if they have any other better options in mind.  

And thank them for their willingness to help you win the negotiation. You’re not at odds, because your opponent in every negotiation is Reality. How the process feels to you and your team will largely depend on how you engage, how open you are to feedback and pushback, and how you respond when it comes. 

Share

When you make the mindset shift, make it explicit to your team and key partners.  You want their help to craft the best deal, and you’re all on the same side of the table.  Once you all see it that way, the negotiation process stops being zero-sum.  Winning the negotiation becomes far less stressful and more fun, when we realize we can all work together and win as a team.

A mistake repeated more than once is a decision.

— ​​Paulo Coelho

Mistakes will happen. Some mistakes will impact timelines. Others will inconvenience teammates, or make your boss look bad. And on and on...

If and how you own up to those mistakes will make all the difference. 

The natural human impulse is to silently hope no one notices or that no one tries to blame you.  Or even worse, we may be tempted to try to pin the blame on someone else. Giving in to these impulses will make the mistake worse for you and your team.

How to Recover

When you make a mistake — one that impacts your colleagues — both you and your colleagues need the same resolution.  All team members directly impacted, including yourself, need you to apologize well. And the quicker the better.  

Apologize (No Faking!)

An effective apology explicitly sends three key messages:

1. I'm so sorry.

2. It was totally my fault.

3. It will not happen again.

Deliver it in a conversation, on the relevant email thread, in the appropriate chat DM or channel, etc. Don't include more people than will care to hear it, but don't try to keep it a secret.

People sometimes try to seek resolution with fake apologies, which is a huge mistake. A fake apology typically makes things even worse.  To be clear, fake apologies are usually softer in some way: 

• Well, sorry, I guess…

• I’m sorry if you felt…

• I’m sorry if I contributed to…

• I’m sorry that [someone else] made a mistake…

• I’m sorry that “we” made a mistake…

• I’m sorry, but also you shouldn’t have…

• Etc. 

Do not deliver a fake apology! Instead, it should sound more like this:

I’m so sorry I caused [some specific harm] by [doing or not doing some specific thing]. It was totally my fault, and I won’t let it happen again.

You don’t need to say those exact words, but you need to clearly send the three key messages, without qualification.  

Mitigate the Impact

To whatever extent is realistic, try to shoulder the burden of cleaning up after the mistake. What this looks like will vary by situation, but the goal is to show a good-faith effort to take practical responsibility.  There may be nothing to be done now, or perhaps the work left to do can only be done by someone else — because you lack the tools or skills to do it. But if you’re capable of doing any of what’s needed, take on as much of the clean-up work as you realistically can.  

Prevent Repeats

The proper apology will repair the relational damage done in the short term, but for the effects to last, it’s critical that you don’t repeat the same mistake you just said wouldn’t happen again. Going forward, try like hell to make sure you don't repeat this kind of mistake.  Because your reputation (even how you see yourself) could be harmed if you repeat it — and the "won't happen again" will ring quite hollow the next time you apologize for this kind of mistake.

Why This Works

Having thought a lot about why this is as effective as I’ve found it to be, I’ve boiled it down to three aspects.  First, it relieves anxiety for whoever I’ve impacted with my mistake.  It also repairs my colleagues’ trust in me and helps contribute to a healthy team culture.  And the final benefit is that this kind of apology puts social pressure on me to avoid repeat mistakes, which results in my own personal growth. 

Relieving Your Colleagues’ Anxiety

Showing remorse and expressing that the fault lies entirely with you will communicate to the team that they don't need to make it their job to convince you that you messed up. Nobody wants to be the performance police, and until you’ve owned the mistake and properly apologized, that’s exactly what it feels like you’re adding to their job description. 

Until the apology is delivered, the impacted colleagues are likely thinking some or all of the following, though perhaps subconsciously: 

• Does he even realize he screwed up?  If not, do I need to be the one to tell him?

• Does he realize how this impacts me and the rest of the team?

• Does he think this is acceptable performance? 

• Is he going to try to deflect blame to make himself look better at my expense?

• I guess I can’t trust him with anything important now. 

• All this has me remembering other frustrating things about him — or things he’s done in the past — and now it feels like they’re starting to really add up. 

• This is stressing me out, and now I’m getting angry. 

Professionals are typically not all that bothered by the impact of the mistake itself, in my experience.  I strongly suspect that the frustration and anger about “the mistake” is usually driven by anxiety about how to deal with the person who made the mistake, rather than dealing with the impacts of the mistake.

But an effective apology usually erases all those thoughts from your colleagues’ minds.  They’ll often even try to talk you into going easier on yourself and attempt to take some of the blame off you. I've seen this response pretty much universally in my career and my personal life. Even somewhat difficult personalities will soften in response to this kind of full apology, in my experience.

Repairing Trust & Developing Culture

The effective apology will salvage as much trust from your team as possible, which is very critical for successful work together in the future. You may even net-gain some trust and respect, depending on the situation.  The apology demonstrates that you’re responsible for yourself and your commitments, so in addition to repairing trust, it can build trust with teammates who don’t already know you well.  They’ll learn that, though you’re human and make mistakes, you’re a trustworthy person who doesn’t just care about yourself. 

Another benefit of the apology is that it sets the right precedent for the team’s culture. You’ve contributed to normalizing accountability and forgiveness. 

Apologizing well is an act of leadership, even if you’re an individual contributor.

Personal Growth

Lastly, telling colleagues this kind of mistake won't happen again should motivate you, both consciously and subconsciously, to work to prevent this kind of mistake in the future — which is the best you could hope for going forward.

What are you going to do right now, to make sure this kind of mistake won’t happen again?  If you leave it up to future-you, the odds are not in your favor. 

Do you need to create or update a document template, a process checklist, a recurring calendar event, or something along those lines — to remind you to be more careful in some particular context?  Do you need to schedule time to memorize something or practice some skill, to be prepared to get it right next time? Or do you need to write “Next time I will do XYZ-thing instead” on the chalkboard 200 times?  

Whatever you need to do to be as confident as possible that you won’t make the same mistake again, tee it up and then “put it in front of the door”, so you are sure to not forget about it. Your reputation and self-image will now depend on it. 

My Own Experience

I first heard this framework many years ago from a comedian, of all people, on his podcast.  As I recall, he didn’t present it as any kind of formal framework or even advice, really.  It sounded off-the-cuff, and he was simply explaining to his guest that whenever someone he works with makes a mistake, these are the three things he wants to hear — so he can be assured he doesn’t need to worry the person is ignorant of their mistake or at risk of making it a habit.  

It made a ton of sense to me, so I decided next time I screwed up at work, I’d try it out. 

At Work

The first time I apologized in this way, there had been a communication gap between my team and another we were working with on a project. It wasn’t solely my fault, but I felt like better communication from either side could have prevented the issues we were now facing.  So I decided I’d own it as my mistake and apologize. 

As I waited for the right moment in the conversation, I was bracing for impact.  My entire body was telling me it was going to backfire and would only confirm in my colleagues minds that I’m unqualified for my role. It felt like they’d immediately go to my boss yelling, “He even ADMITTED it was his fault!”

But instead, my teammates and partners jumped in to defend me (seemingly from myself).  They started to call out aspects of our situation that they felt responsible for, and the conversation immediately turned from tense and adversarial, to positive and collaborative. No one was upset with me at all, and we were all of a sudden focused solely on how best to move forward. 

Subscribe now

I was blown away by how well it worked!  The next time, it was a little easier, but it still felt scary.  I kept waiting for someone to take advantage of my vulnerability, but after nearly a decade of handling my mistakes this way, I’ve yet to have it backfire even once, and apologizing like this is now second nature. 

Outside of Work

This approach to handling my mistakes worked so well for me at work, that I started to use it in my personal relationships as well.  I’m now quick to give a proper apology to anyone impacted by something I’ve done wrong or could have done better — my wife, my kids, my parents, and my friends. 

It works just as well in any context. The dynamics are pretty much the same, allowing me to build trust rather than lose it.  Grow and improve, rather than cement my shortcomings. 

Share

I now even go so far as to apologize to myself using the same script, when I’ve made a mistake I’m upset about.  If I forgot to put the trash out on time or spill my coffee on my keyboard, I can get frustrated with myself about the hassle I’ve caused with my mistake.  There seems to be some part of me who is satisfied by a proper apology, even if it’s me saying it to myself.  

I’m no psychologist, but I suspect that all the same dynamics are at play inside my own brain as when the offended party is someone else. And just like I’m happy to forgive anyone else’s honest mistake, it seems I’m able to forgive my own. It’s funny, but it works for me. 

This essay describes how I handle what I’d call small to medium-sized mistakes, where the stakes are largely impacts to my colleagues workload and timelines — or where my mistake diminished the value of work others have done.  

For higher-stakes situations, this is not sufficient advice and may in fact be the wrong advice to follow: 

• This is interpersonal relationship advice, not legal advice. If you are involved in a car crash or work in the medical industry or find yourself in another context where admitting fault could have legal implications, seek advice from a licensed attorney or other expert in the relevant field, not a rando with a keyboard and an internet connection! 

• This is not sufficient advice for how to handle financially impactful production incidents, security breaches, or any any issues that will concern numerous stakeholders across your organization due to harm caused to your business or brand. This advice might play a part in an effective strategy for handling these kinds of crises, but it’s not a sufficient playbook for highly visible and more prickly situations. 

Every question you have about product management or your current PM role has the same answer: 

It depends. 

In fact, it’s a bit of a trope in product management communities, even to the point of being a cliche.  But if it’s indeed cliche, that’s only because it’s true enough to bear repeating. 

“What is the best tool and format for a roadmap?”  It depends.  Who all cares about your roadmap?  What do they need to know about it and when?  Does your org have a standardized tool or template, or does everyone do something different?  What kind of product is it, and how does it relate to other products at your company?  

Anyone’s recommendation about how to roadmap is only as good as their context is similar to yours — and that assumes they’ve found the right answer for their own context, which is not a given!

In software, we don’t build the same thing twice, and I suspect that fact is at the root of the issue. In our code bases, we reuse anything that already exists and solves the problem well — classes, functions, and libraries.  In our user interfaces, we reuse styles, layouts, and interaction patterns.  And for entire software products, we only build a new product if we can’t best address our problem or opportunity by “buying” (i.e. acquiring an existing company’s product) or “borrowing” (i.e. hiring a vendor’s solution or partnering with another company to integrate with their existing offering). 

If we’re building something, it’s because it’s new and novel.  No one has built it before, let alone us ourselves. 

I imagine that industries like commercial air travel, residential construction, dentistry, and hospitality all suffer far less from this dynamic.  The same planes fly the same routes on the same schedule (ideally) over and over.  Construction standards and local building codes apply to every house in the neighborhood, and often the same floor plan is used for multiple houses in a subdivision.  Dental offices do the same procedures over and over for different patients throughout the week.  And hotels welcome new guests into the same rooms, night after night. I’m sure there are nuanced differences from day to day, but all of these industries and many others — which involve atoms rather than just bits — require a lot of repeating the same effort over and over.  So finding “the right way” to do any particular part of a job is probably much more realistic. 

But in software, where you never build the same thing twice, it’s hard to find enough similarity among situations to make any concrete tactical advice broadly useful.  

Not only do we never build the same thing twice, but in aggregate, we also make software products for virtually every industry and problem domain. And to complicate things further, we all have products at different stages of their life cycles, within companies of different ages and sizes. 

And then there’s the people we work with, literally none of whom are the same, arranged into various cross-functional teams and organizations — with different structures, functional roles, leaders, cultures, business models, and strategic objectives. 

We could go on and on, exploring all the various dimensions that make up the context that any given PM finds herself in on any given day. If we spent enough time, we could fill volumes with the various differences between one PM’s context — the industry, market, company, organization, product, and team — and that of any other PM. 

So every PM is on their own then?  I don’t think so.  But we need to be very careful what we expect PM advice to do for us. 

Any given source of advice for PMs — a book, a podcast, a blog, or YouTube channel — can’t be treated as a cohesive playbook.  We can’t just memorize all the plays and run them with our team.  We need to learn the component parts of each play and understand what makes it effective where it’s used.  Then, we need to start to build up our own playbook, for our own context, based on those underlying principles. And then be flexible enough to edit our playbook as our context evolves and our judgment improves. 

“The PM’s job is mainly talking to customers!”  But what about at a company that has a Product Ops function and a dedicated User Research team? 

“A PM needs to be technical enough to get in the weeds with engineers about tradeoffs!”  But what about in an org where Product is expected to focus entirely on problem definition and prioritization and engineers are comfortable working with Design to shape and execute on a solution? 

“PMs need to be data-driven and focused on driving metrics with A/B tests!”  But what about at a B2B SaaS startup with only 2 customers and a total of 6 users? 

Applying advice in your role, when it’s intended for a context very different from yours, will at best be unhelpful.  At worst, it will make you ineffective and make your colleagues miserable. 

Subscribe now

It’s not the advice you need as a PM.  It’s the wisdom you develop over time — as you repeatedly take in advice, discern the principles that underpin it, and then try to apply those principles in your own context whenever and however you think they make the most sense.  The more you work through this cycle, the more you train your brain to recognize patterns and identify how best to operate in any given context and respond to each new challenging situation. 

Since we never build the same thing twice, and every context is different, figuring it out on the fly is the job.  Our work in Product is closer to playing Jazz Improvisation than classical music, so there’s no sheet music to master before we take the stage. You don’t need to memorize the “best” framework. You need to study a broad set of advice and resources, get reps applying what seems useful, ask for and listen to feedback, and then repeat — strengthening your own judgment over time. 

Share

It always depends, and it’s your job to figure out what exactly it depends on.  It’s slow, and it’s hard.  But it’s the reality, and it can be really satisfying.  

Try to learn to enjoy it!

As Soon as We Wrap Up Here

“I’m hoping to get home early today, if I can,” explains Jane. “My kid was starting to get the hang of hitting a tennis ball last summer, and this is the first weather we’ve had this year to get him back out on a court to try to regain some of the momentum.”

“Oh, that’s so fun,” I affirm. I had gone through a tennis phase as a kid and loved it. 

Jane is the highest-horsepower programmer I’ve ever worked with.  She’s written large portions of our codebase singlehandedly, but always has the time and patience to help me understand technical aspects of our product, whenever I realize I’m naive to something I think is important to understand.

Tom, who had moved from the East Coast when he joined the company, was hosting his parents for the week. “They’re flying back to New York on Monday, so I’m trying to show them as much of the city as we can cover this weekend,” offered Tom. “I’m gonna go pick them up, as soon as we wrap up here.”

No Grace Period

As we reach the door to the conference room, we all see that it’s still occupied for the meeting prior to ours.  We can’t see who is in the room, as most of the room’s glass wall against the hallway is frosted. But we can see the feet of the group sitting around the table. 

Jane checks her watch and mutters something under her breath. “I’m knocking if they’re not out in the next 25 seconds,” she announces to Tom and me. “I can head out as soon as we’re done with this meeting, so it’s our room at 4 PM on the dot — no grace period!”  

Tom and I exchange a look and chuckle at her sarcastic tone, mostly because we’re not sure it’s entirely sarcasm.

It’s Our Room

The door opens from the inside with 10 seconds to spare. We exchange hellos with the group that exits, and we all grab a seat — mine nearest the far end of the table, so I can plug my laptop into the TV hanging on the wall.  The sun shining on the parking lot outside — which isn’t a given in the Portland area — won’t be up for much longer.  Time is of the essence.  

Perhaps not the optimal moment for a philosophical debate. Nevertheless, here we are.

I Just Need Requirements

Our team is responsible for the APIs for checkout in all of our company’s 12 commerce-enabled digital experiences across North America, Western Europe, China, and Japan — and we dive into discussing my sketch of a plan for an upcoming project. 

I’m not done reading aloud the first bullet in the “Open Questions” section of the doc, when for the third time in about a month, Tom starts into a rant that by now feels almost as familiar as the “Chinese Restaurant” episode of Seinfeld.

Tom interrupts my question about the technical implications of the planned scope, announcing, “I just need requirements.  Tell me exactly what to code, and I’ll code it…” He goes on for about 30 seconds. 

When Tom finishes making this familiar plea, I take a beat, to try to estimate how much trust I have with Tom.  He’s a very capable engineer, who I know always wants to do the right thing for our users, product, and company. We have a good rapport socially, and he’s complimented me before on my ability to PM our unusually technical product.  I’m not sure if Tom will be persuaded by pushback, but he’ll at least hear me out.  

Totally Fair Game

If I say what I’m actually thinking, it will be the first time I’ve ever said the quiet part out loud.  I’ve been thinking it, silently, for at least a couple years, but I’ve never vocalized it to anyone before. 

This prolonged pondering is very much a Dan thing to do. It’s not so much that I have imposter syndrome or low self-esteem. I have no self-esteem. Not negative, nor positive — just a blank whiteboard. I’m now confident in plenty of situations, especially professional ones, but only once I feel it’s been earned. Until that mental whiteboard lists more pros or cons as relevant evidence of my competence or preparation, I’m neither confident nor insecure in a given situation. I can’t put my finger on the precise moment I unconsciously adopted this posture, but I do have a list of suspects under investigation.  

I am an only child. There is one of us. When people speak of “strength in numbers”, I have to assume that 1 is not among the “strong” numbers to which they refer. 

I was homeschooled through my 7th grade year, during which a cute girl my cousin was friends with seemed to find endless amusement in my mentioning that the next day I would “do school” before going to basketball practice. I’ve since learned this is not a common phrase for American teens. 

When I played basketball in elementary and middle school, I wore sports goggles with prescription lenses — think Kareem Abdul-Jabar, only pasty white, 5’ 8”, and coming off the bench. Shocking as it may seem, sports goggles are not a high-status fashion accessory in 7th grade, especially with 7th grade boys who all know each other from class and are introduced to you as the kid who is somehow on the school’s team without actually attending the school. 

And while my hair is darker now (and hard to notice with my receding hairline and buzz-cut), I had red hair into adulthood. While most adults are blissfully unaware, red hair actually is the last remaining physical attribute a human can possess that society deems totally fair game for mockery. 

At some point, I gathered that I need to earn social capital. I have neither the face, nor the personality, to realistically expect it to fall in my lap.  So floating a heretical notion, as pushback to Tom, feels far from a safe move — especially on this rare, temporary sunny Friday afternoon. 

What if I’m wrong?  I can live with that, and it’s better to be convinced I am than stay wrong longer than I need to.  Worse though, what if I’m right, but I fail to articulate my argument well enough to persuade? I may learn something about how to better make the case next time, I suppose. Perhaps worst of all, what if I try to make my case, and Jane and Tom couldn’t care less — just becoming frustrated that I’m dragging out this meeting?

Only way to find out for sure is to ship. So, I take a breath and then let it rip.

There Are No Requirements

“Well, here’s the challenge with the notion of ‘requirements’ though,” I begin to explain to Tom.  

“There are no requirements.  I could write a bunch of stuff down and tell you it’s all required, but the only real requirement is to build the best thing we can — and no one person on our team is equipped to figure that out on their own.”

Hoping to make clear that I’m not trying to abdicate any of my role’s responsibilities, I add, “Don’t get me wrong though; I’m doing everything I can to make sure the problem is very valuable to solve and clearly articulated, before we start investing the rest of the team’s time.  And I do my best to sketch out a draft of a plan — hypothetical scope and potential shape — for how it may all work well.”  

I pause, noticing a contemplative look on Tom’s face. 

“But if we try to solve it exactly how I think is best, it’s going to be worse than it could be if the rest of the team is involved in making design decisions and trading off scope based on complexity and effort.  You all have a ton of important knowledge and skills that I don’t.”

I then pull up a diagram to show on the TV at the front of the room, illustrating our domain’s APIs, the microservices behind them, and our key downstream dependencies. 

Shifting my eyeline away from Tom on my left, toward the large TV to my right, I continue, “We’ve got five front-door APIs, and they all need to work well together for all 12 of our front-end teams.  And every request to each of those APIs depends on some number of the two dozen microservices in our domain — most of which depend on some mix of at least a half dozen downstream domains, so—”

Before I can finish making my point, another voice interjects.  

Where You’re Coming From

“And we support six different product types, which each have different buyability rules and factors impacting when and how they can be fulfilled in various situations,” adds Jane, the most senior engineer on our team. She continues at a swift pace, ”Different product types can be combined into a single cart and delivered to various location types via one or more fulfillment types.”

Whenever Jane speaks on technical topics, she almost always speaks quickly. But it still feels like her mouth’s ability to vocalize words is a giant bottleneck for getting her thoughts out of her head and delivered to the rest of us. It’s lucky for us that her voice can’t go as fast as her brain, or none of us would have a chance of keeping up!  Jane is deeply respected as an expert across our entire team, including myself, so her support carries a lot of weight in any team discussion. 

She continues, “And then a lot of our system’s behavior differs based on the country the user is shopping in.  Our system is complex enough that I’m sometimes surprised by something I hadn’t thought of until I’m part-way done coding a change. If I can’t think of everything up front, how could Dan, who isn’t in our code base every day, spell out exactly what’s required?”

My eyes slowly widen.  

Wait, I’m not alone in making this argument?!  

Trying to bring it home, I thank Jane for her perspective and conclude, “So yeah, it’s all way too complex for me to foresee all possible scenarios we need to handle in every service, and spell it all out in detail before we start development.  And even if I could, I should not be making every single one of those product decisions in a vacuum, right? Is there any chance I’d make every decision correctly ahead of time — without leaning on the rest of the team now, and even as we discover decisions we need to make during development?”

As I stop talking, I unconsciously hold my breath.  Now it’s Tom’s turn to take a beat, as he considers my pushback. 

It takes, in my estimation, approximately 18 months of silence for the next five seconds to tick by on the clock in the corner of my laptop screen.

The tension peaks as Tom finally starts to reply, “Ok, yeah, that does make sense, actually.  Thanks for explaining where you’re coming from.”

Wow, it worked!

I try hard to not let my delight show on my face, as we continue our discussion.  We then proceed to review and pick apart the planned scope and design — this time, with Tom fully engaged in the discussion. We go on identifying gaps in the plan, aspects that may not be technically feasible, parts that may be more effort or cost than they’re worth, and even ideas Tom and Jane have that I haven’t thought of, to improve how the design would support the front-end user experience that our APIs will be enabling 

But Not Really

In the coming weeks, I’d eventually realize it had not worked entirely. 

I’d convinced Tom of my points intellectually, but on some level, that wasn’t enough. Over the next 2 years that the three of us would continue working together on that team, Tom would rerun the “Plea for Requirements” episode of his sitcom in syndication, at least once per quarter. 

But, I understand from getting to know him over the years, that Tom’s posture had been formed based on his frustrating experiences with Product folks in the past, who were either lacking in competence or work ethic, failing to drive appropriate clarity for engineering.  So I totally get his desire for clarity. If you get burned badly enough in any context, it’s natural to build fences that defend against repeat offenses.  

While I had not fully convinced Tom, something had changed in me.  Jane’s support for my argument poured wet concrete into the form I’d laid in my mind.  She is whip smart and extremely effective.  And we are always able to be extremely effective working together.  If she was willing to cosign my assertion that there are no requirements, I wasn’t as far out on a limb as I feared. 

It was formative validation and would help me to refine how I’ll work with my teams going forward.  I now have more evidence on which to base my confidence. And working with other teams, on other products, in the coming years — the evidence will continue to mount. 

Generally speaking, there are no requirements. 

No More Stone Tablets

In hindsight, it maybe shouldn’t have been a complete surprise that Jane chimed in to help make my point. After all, working with her over the prior 18 months had helped to solidify my perspective about the mirage of “requirements”.  She was always quick to contribute to product thinking, leveraging her deep technical expertise.  

Jane would sometimes ask, “Would it work about as well if it worked this way instead of that way? Because if so, it would save about two weeks of development time.”  And she would sometimes even give non-technical pushback, things like, “Wouldn’t it be more clear for the user to see that information in the Cart screen, rather than having to wait until they proceed to the Shipping step of checkout?”  

She intuitively understood that almost everything is negotiable.  That’s why I loved working with Jane!

Working closely with experts from other functions, like Jane, who wanted to join me in the process of figuring out what the best thing to build was, had convinced me over time that it would be hubris to present what I thought we should do as being “required”.  Collaborating with key engineering and design partners (and sometimes others too), we’d always arrived at a better plan than I first presented. 

And even after we started development, we would sometimes discover decisions to be made — or find reasons the plan should change. Even after up-front collaboration, we hadn’t really found “requirements” but instead a better plan. Since plans can change, we would still opt to pivot, if and when we learned more.

If even Tom could be convinced — at least intellectually — that the notion of “requirements” was closer to a fantasy than an ideal to organize our team’s entire workflow around, I suspected this heretical thought didn’t need to be kept such a secret. 

Since then, I’ve become honest and forthcoming with all my teammates on this topic, typically raising it in my first 1:1 with each new colleague:

I’ll try to rarely use the word “requirements”, because almost nothing is truly required. Since you and the rest of the cross-functional team will have really relevant knowledge and skills that I don’t, we’re going to have to collaborate to figure out the best thing we can build.  So please always be vocal about any input, feedback, and even pushback you may have about the planned scope and solution design.  If you can foresee a pitfall or think of a way to solve the problem with less effort, I hope you’ll speak up so we can factor that into our plan. All I want is to get to the best product we can, and I believe that takes all of us.

Isn’t this just semantics though?  No, I think it’s an impactful mindset shift for me and the entire team.  

Subscribe now

While some teammates I’ve worked with, like Jane, naturally ignore the “requirements” terminology and dig in without prompting — many aren’t as bold.  But I’ve found many more teammates, Tom included, are willing to contribute to the product beyond their narrowly prescribed functional lane, when I disavow the usual premise.  No one is better off when we share in the delusion that only Product people are qualified to think about what to build — trekking up to the mountaintop and coming back with “requirements” etched on stone tablets.

Yes, sometimes there are actual requirements, and I try to reserve the term for exactly those situations.  But for most products, very little is truly required, if anything at all. 

Share

The requirement is to build the best product we can, and getting there takes all of us. 

The preceding is a reconstructed narrative based on actual events. Names have been changed, and some details have been condensed or rephrased to concisely illustrate the core experience.