Steve didn’t just read a script for the presentation. He’d been telling a version of that same story every single day for months and months during development—to us, to his friends, his family. He was constantly working on it, refining it. Every time he’d get a puzzled look or a request for clarification from his unwitting early audience, he’d sand it down, tweak it slightly, until it was perfectly polished.

He talked for a while about regular mobile phones and smartphones and the problems of each before he dove into the features of the new iPhone. He used a technique I later came to call the virus of doubt. It’s a way to get into people’s heads, remind them about a daily frustration, get them annoyed about it all over again. If you can infect them with the virus of doubt—“maybe my experience isn’t as good as I thought, maybe it could be better”—then you prime them for your solution. You get them angry about how it works now so they can get excited about a new way of doing things.

when I say “story,” I don’t just mean words. Your product’s story is its design, its features, images and videos, quotes from customers, tips from reviewers, conversations with support agents. It’s the sum of what people see and feel about this thing that you’ve created.

When you get wrapped up in the “what,” you get ahead of people. You think everyone can see what you see. But they don’t. They haven’t been working on it for weeks, months, years. So you need to pause and clearly articulate the “why” before you can convince anyone to care about the “what.”

That’s the case no matter what you make—even if you sell B2B payments software. Even if you build deep-tech solutions for customers who don’t exist yet. Even if you sell lubricants to a factory that’s been buying the same thing for twenty years.

If your competitors are telling better stories than you, if they’re playing the game and you’re not, then it doesn’t matter if their product is worse. They will get the attention. To any customers, investors, partners, or talent doing a cursory search, they will appear to be the leaders in the category. The more people talk about them, the greater their mind share, and the more people will talk about them.

A good story is an act of empathy. It recognizes the needs of its audience. And it blends facts and feelings so the customer gets enough of both. First you need enough instincts and concrete information that your argument doesn’t feel too floaty and insubstantial. It doesn’t have to be definitive data, but there has to be enough to feel meaty, to convince people that you’re anchored in real facts. But you can overdo it—if your story is only informational, then it’s entirely possible that people will agree with you but decide it’s not compelling enough to act on just yet. Maybe next month. Maybe next year.

So you have to appeal to their emotions—connect with something they care about. Their worries, their fears. Or show them a compelling vision of the future: give a human example. Walk through how a real person will experience this product—their day, their family, their work, the change they’ll experience. Just don’t lean so far into the emotional connection that what you’re arguing for feels novel, but not necessary.

And always remember that your customers’ brains don’t always work like yours. Sometimes your rational argument will make an emotional connection. Sometimes your emotional story will give people the rational ammunition to buy your product. Certain Nest customers looked at the beautiful thermostat that we lovingly crafted to appeal to their heart and soul and said, “Sure, okay. It’s pretty” and then had a thrilled, emotional reaction to the potential of saving twenty-three dollars on their energy bill.

everyone will read your story differently. That’s why analogies can be such a useful tool in storytelling. They create a shorthand for complicated concepts—a bridge directly to a common experience.

That’s another thing I learned from Steve Jobs. He’d always say that analogies give customers superpowers. A great analogy allows a customer to instantly grasp a difficult feature and then describe that feature to others. That’s why “1,000 songs in your pocket” was so powerful. Everyone had CDs and tapes in bulky players that only let you listen to 10-15 songs, one album at a time. So “1,000 songs in your pocket” was an incredible contrast—it let people visualize this intangible thing—all the music they loved all together in one place, easy to find, easy to hold—and gave them a way to tell their friends and family why this new iPod thing was so cool.

Because to truly understand many of the features of our products, you’d need a deep well of knowledge about HVAC systems and power grids and the way smoke refracts through a laser to detect fire—knowledge almost nobody had. So we cheated. We didn’t try to explain everything. We just used an analogy. I remember there was one complex feature that was designed to lighten the load on power plants on the hottest or coldest days of the year when everyone cranked up the heat or AC at once. It usually came down to just a few hours in the afternoon, a few days a year—one or more coal power plants would be brought on line to avoid blackouts. So we designed a feature that predicted when these moments would come, then the Nest Thermostat would crank the AC or heat up extra before the crucial peak hours and turn it down when everyone else was turning it up. Anyone who signed up for the program got a credit on their energy bill. As more and more people joined the program, the result was a win-win—people stayed comfortable, they saved money, and the energy companies didn’t have to turn on their dirtiest plants. And that is all well and good, but it just took me 150 word to explain. So after countless hours of thinking about it and trying all the possible solutions, we settled on doing it in three: Rush Hour Rewards.

Everyone understands the concept of rush hour—the moment when way too many people get on the road together and traffic slows to a creep. Same thing happens with energy. We didn’t need to explain much more than that—rush hours are a problem, but when there’s an energy rush hour, you can get something out of it. You can get a reward. You can actually save money rather than getting stuck with everyone else.

Quick stories are easy to remember. And, more importantly, easy to repeat. Someone else telling your story will always reach more people and do more to convince them to buy your product than any amount of talking you do about yourself on your own platforms. You should always be striving to tell a story so good that it stops being yours—so your customer learns it, loves it, internalizes it, owns it. And tells it to everyone they know.

A good product story has three elements: It appeals to people’s rational and emotional sides. It takes complicated concepts and makes them simple. It reminds people of the problem that’s being solved—it focuses on the “why.”

Haptic sensations feel rewarding, so users feel compelled to repeat these actions.What's the optimal length for vibrations? Try 400ms

But what if you sell products on desktop?Instead of using vibrations, try animating products upon selection. Move items into the basketShake from side to sideGrow and shrink

In an online grocery store, customers bought more items when they felt vibrations while adding items to their cart (Hampton & Hildebrand, 2021).

Classical Conditioning. Vibrations often co-occur with social messages. Therefore, vibrations feel good because these sensations have been frequently paired with hits of dopamine (Hampton & Hildebrand, 2021).Perceived Ownership. Vibrations mimic touch, as if you are physically touching an item on your device. And touch is key to ownership (Li, Cowan, Yazdanparast, & Ansell, 2024; Peck, Barger, & Webb, 2013).

Muse as a brand and a product represented something aspirational. People want to be deeper thinkers, to be more strategic, and to use cool, status-quo challenging software made by small passionate teams. These kinds of aspirations are easier to indulge in times of plenty. But once you're getting laid off from your high-paying tech job, or struggling to raise your next financing round, or scrambling to protect your kids' college fund from runaway inflation and uncertain markets... I guess you don't have time to be excited about cool demos on Twitter and thoughtful podcasts on product design.

I’d speculate that another factor is the half-life of cool new productivity software. Evernote, Slack, Notion, Roam, Craft, and many others seem to get pretty far on community excitement for their first few years. After that, I think you have to be left with software that serves a deep and hard-to-replace purpose in people’s lives. Muse got there for a few thousand people, but the economics of prosumer software means that just isn’t enough. You need tens of thousands, hundreds of thousands, to make the cost of development sustainable.

We envisioned Muse as the perfect combination of the freeform elements of a whiteboard, the structured text-heavy style of Notion or Google Docs, and the sense of place you get from a “virtual office” ala group chat. As a way to asynchronously trade ideas and inspiration, sketch out project ideas, and explore possibilities, the multiplayer Muse experience is, in my honest opinion, unparalleled for small creative teams working remotely.

But friction began almost immediately. The team lead or organizer was usually the one bringing Muse to the team, and they were already a fan of its approach. But the other team members are generally a little annoyed to have to learn any new tool, and Muse’s steeper learning curve only made that worse. Those team members would push the problem back to the team lead, treating them as customer support (rather than contacting us directly for help). The team lead often felt like too much of the burden of pushing Muse adoption was on their shoulders. This was in addition to the obvious product gaps, like: no support for the web or Windows; minimal or no integration with other key tools like Notion and Google Docs; and no permissions or support for multiple workspaces. Had we raised $10M back during the cash party of 2020–2021, we could have hired the 15+ person team that would have been necessary to build all of that. But with only seven people (we had added two more people to the team in 2021–2022), it just wasn’t feasible.

We neither focused on a particular vertical (academics, designers, authors...) or a narrow use case (PDF reading/annotation, collaborative whiteboarding, design sketching...). That meant we were always spread pretty thin in terms of feature development, and marketing was difficult even over and above the problem of explaining canvas software and digital thinking tools.

being general-purpose was in its blood from birth. Part of it was maker's hubris: don't we always dream of general-purpose tools that will be everything to everyone? And part of it was that it's truly the case that Muse excels at the ability to combine together so many different related knowledge tasks and media types into a single, minimal, powerful canvas. Not sure what I would do differently here, even with the benefit of hindsight.

Muse built a lot of its reputation on being principled, but we were maybe too cautious to do the mercenary things that help you succeed. A good example here is asking users for ratings; I felt like this was not to user benefit and distracting when the user is trying to use your app. Our App Store rating was on the low side (~3.9 stars) for most of our existence. When we finally added the standard prompt-for-rating dialog, it instantly shot up to ~4.7 stars. This was a small example of being too principled about doing good for the user, and not thinking about what would benefit our business.

Growing the team slowly was a delight. At several previous ventures, I've onboard people in the hiring-is-job-one environment of a growth startup. At Muse, we started with three founders and then hired roughly one person per year. This was absolutely fantastic for being able to really take our time to find the perfect person for the role, and then for that person to have tons of time to onboard and find their footing on the team before anyone new showed up. The resulting team was the best I've ever worked on, with minimal deadweight or emotional baggage.

ultimately your product does have to have some web presence. My biggest regret is not building a simple share-to-web function early on, which could have created some virality and a great deal of utility for users as well.

In terms of development speed, quality of the resulting product, hardware integration, and a million other things: native app development wins.

After decades working in product development, being on the marketing/brand/growth/storytelling side was a huge personal challenge for me. But I feel like I managed to grow into the role and find my own approach (podcasting, demo videos, etc) to create a beacon to attract potential customers to our product.

when it comes time for an individual or a team to sit down and sketch out the beginnings of a new business, a new book, a new piece of art—this almost never happens at a computer. Or if it does, it’s a cobbled-together collection of tools like Google Docs and Zoom which aren’t really made for this critical part of the creative lifecycle.

any given business will find a small number of highly-effective channels, and the rest don't matter. For Heroku, that was attending developer conferences and getting blog posts on Hacker News. For another business it might be YouTube influencer sponsorships and print ads in a niche magazine. So I set about systematically testing many channels.

When I first started meeting founders, I wanted to help with anything and everything. Unfortunately, that's neither realistic or possible. For example, I have many responsibilities at my day job that must come first. Over time, I have honed in my pitch to be explicit about how I can and can't help. See the notes above about ways to be helpful, and find your own unique combination of value to bring to the table.

My contract typically looks like this: We agree to meet ~X hours per quarter/half/year Multiply by Y contracting rate Y ⨉ X = some dollar amount Z Divide Z by the startup's latest price per share to arrive at a number of advisor shares to grant

Be founder-friendly! It's a big deal and a lot of paperwork to get a smaller check or advisor on the cap table (unless they already have a lot of operational infrastructure in place) – this usually means being relaxed about the commitment paperwork or helping out pro-bono for the first few hours while they work through the logistics.

Finding founders you work well with can be a numbers game; you won't be sure what you like doing until you've met a handful of founders, done several advisory meetings, and poked at different types of problems. It's okay to dip your toe and warm up to the process before committing a lot of time and energy to this. I started slow, and have been steadily sharpening my own intuition about what kinds of products and founders get me excited, and where I can add unique value