Platform PMs dogfood the wrong project

I was getting ready to publish HanziHover, a Chrome extension I built to help me learn Chinese. You turn it on when you want to study, hover over a word to see the translation, and save the words you want to remember as flash cards to quiz yourself on later. The code was done. All that was left was the store listing, so I pulled up the listings of the top extensions in the store and studied what they had done. Which feature did they lead with? How much text did they put on the image? Were they showing the product, or what it felt like to use it?

Somewhere in the middle of that, I got curious about what I’d done for the last extension I published, back when I worked on the Chrome extensions platform. The answer: I took one quick screenshot and called it a day.

That gap turned out to be a small version of something bigger. I spent five years on the Chrome extensions platform and the Chrome Web Store, and I built extensions along the way to try things out. But when you build an extension to test the platform, you pick one the platform is good at. When you build one because you want it to exist, you find out where it isn’t. Building HanziHover a year after leaving Google changed what I ran into, how much each problem hurt, and what I reached for to solve it.

What I ran into: test projects are picked to be easy

The last extension I’d published was XKCD Subtitler, which puts the alt-text of XKCD comics directly below the image. The alt-text is often part of the joke, and I didn’t want to have to hover over the comic to read it. It was only a few lines of code and very quick to write (yes, even though AI coding didn’t exist at the time).

That was on purpose. When your goal is to try out a platform, you pick a project that’s good for trying out the platform. You want to see the docs, the setup flow, the APIs, and what publishing looks like, so you pick an idea that’s quick to build and has very few tricky parts. That kind of test teaches you a lot about the new developer experience. Is there enough documentation? When someone lands on an empty dashboard, do they know how to get started? I’ve done this kind of test myself, I’ve seen plenty of other PMs do it, and it’s hard to tell anyone to stop, because it does produce useful results.

That’s what makes it a trap. The same instinct that keeps a test project small also steers it around the hardest parts of the platform. You’re just skipping work that isn’t the point of the test, and a lot of the hardest parts of building on a platform are exactly that kind of work. And because the test went well, you walk away feeling like you understand the developer experience as a whole.

HanziHover started from a goal instead, and the requirements came from the goal. Side by side, the difference looks like this:

	XKCD Subtitler	HanziHover
What it stores	Nothing	A word list built up over weeks
Accounts	None	Login, so the list syncs
Backend	None	Supabase, on its free tier
Store images	One quick screenshot	Four designed images, after studying the top listings

Most of those rows trace back to one thing: HanziHover holds something its users care about. I wanted my words to follow me when I switched computers or browsers, and I didn’t want my list to get accidentally blown away, so keeping it in the browser’s own storage got ruled out early. That meant a real backend. A backend meant users needed to log in, so the right list showed up for the right person. And since this was a hobby project, it meant finding a service with a free tier (thank you, Supabase) and staying inside it. No test project I would have picked for myself needed any of that.

These problems also tend to show up in the middle of a project rather than at the start, which is what makes them dangerous. Friction when getting started costs someone a frustrating afternoon, before they’ve invested much. Friction in the middle arrives after they’ve committed to an idea, at the point where a hobby project picks up an account to manage and a usage limit to watch. That’s the kind of pain that lets someone finish the extension in front of them and never come back to build another.

How much it hurt: building it changes the weight of each problem

When you’re looking at metrics or summarizing customer interviews, it’s tempting to say “X developers ran into problem A” and “Y developers ran into problem B,” and in doing so, you reduce the pain to a number. But feedback usually follows a long tail: a few deal-breakers, then a long list of nice-to-haves that people will live with. In a spreadsheet, both just look like a row.

Storing user data is a good example of how the weight shifts. Before anyone has used your extension, saving their data feels like a nice-to-have. After someone has spent weeks building up a word list, losing it is a deal-breaker, and they probably aren’t starting over. In a developer survey, “needed a backend” is one line out of many. When you’re the one building, it’s the requirement everything else depends on.

The screenshots work the same way. If your reaction is “well, obviously good extensions make nice screenshots,” then my response is: yes, but is it instinctively obvious when you’re making a split-second decision?

That kind of internalized intuition is what speeds up execution. Say someone proposes a store page that features extensions using their first screenshot. One response is to ask for more data: “Some developers make utilities where the screenshots aren’t great, so we might not be able to rely on them. Let’s sample the top 100 extensions and do an analysis first.” Another is to move forward with a clear underlying belief: “Mainstream extensions put real thought into their first couple of screenshots, so we can be confident the ones we feature will have good images to show.” Both are reasonable. The second one ships weeks sooner, and the difference is mostly whether the PM has sat there and agonized over their own listing images.

What I reached for: real projects use whatever works

A test project uses your platform’s own pieces, because that’s what you’re testing. A real project reaches for whatever meets the requirement, and that hides one more thing from a platform PM: how your platform sits next to everyone else’s.

When you work inside a big ecosystem like Google, Apple, or Microsoft, it’s easy to absorb the unified story your company tells, where every demo runs on the company’s own hardware, apps, and services. But reality is never as clean as the stories we tell.

You might have noticed that I used Supabase for HanziHover, not Google’s own Firebase. That wasn’t really a decision. I asked Claude to help me architect the whole extension, and as part of that longer prompt, I asked for a way to store a user’s words for free, because I didn’t want to pay for storage on a hobby project. It suggested Supabase. Firebase never came up, because I never asked for a list of options, and Supabase did what I needed.

The AI part is new, but the logic behind it isn’t. Even without an assistant, I would have started from my requirements (free, a word list per user, synced across machines) and gone with the first thing that met them. Wanting “my words, on whatever computer or browser I’m on” has nothing to do with which company’s ecosystem I happen to be in.

AI just makes this more extreme. When a recommendation comes from a list of requirements, nobody stops to ask whether the pieces come from the same company. Either your product fits what the developer asked for, or it doesn’t get mentioned at all.

And as a project grows, it picks up more dependencies, one requirement at a time. If I keep developing HanziHover, it’ll probably end up looking more like my apartment in my early working years than an IKEA brochure. So many extension, website, and app developers live in this world, each with an eclectic collection of technologies accumulated over time, battle scars from the warfare known as “evolving business requirements.”

Your platform is the center of your roadmap, but it’s rarely the center of your customer’s architecture.

If you can’t build it, borrow it

None of this replaces research. While I was at Chrome, I didn’t have only my own intuition to rely on. I worked with a developer relations team that spent nearly all their working hours with the developer community, understanding their needs and bringing what they learned back to product and engineering. Thanks to them, I didn’t need a perfect mental model of the developer experience to make good decisions, and building HanziHover gave me a much better appreciation for how much they brought into the room.

Not every team is lucky enough to have a group like that. Building something real on your own platform is one way to close the gap. Another is getting your team to watch someone live through the product.

I saw this work years ago at Lob. A customer success manager teamed up with an engineer to act out a skit of a customer trying to use one of the functions in our customer dashboard. It was entertaining, and we did enjoy the antics, but we were also horrified by the actual product experience. The skit was dramatized, but the scenario wasn’t unrealistic. The most horrifying part was that the product projected behind them was our real product, working exactly as designed. Those issues were fixed that same month, and nobody in the room needed a spreadsheet to know how much they hurt.

Build something you actually want

“Use your own product” is advice everyone already gives, so mine is a bit more specific. Don’t invent a project that makes your platform easy to test. Pick something you actually want to exist. Hold it to a quality bar you’d be happy showing a friend, and try to get it into the hands of real people. Then pay attention to the moments when you catch yourself changing the idea to fit the platform. Those are the gaps your test projects were built to avoid.

I never would have spent that long on a screenshot for XKCD Subtitler, which is exactly why it couldn’t teach me what HanziHover did.