Last December we got on a call with our friends at beehiiv to talk about building a community feature into their platform. Community was the most requested feature they had. Not one of the most requested. The most.
We showed up with eight questions, and we did not agree the project existed until we had answers to all of them.
Why bother doing more discovery when users have already requested something so much?
Well, a request that popular has enormous gravity inside a company. People start designing against it in their heads. Somebody builds a slide deck…or nowadays, a Claude prototype! By the time a budget number gets attached, the thing has started to take on a shape nobody deliberately chose, and the question of what problem it solves has started to become unclear because everyone assumed somebody else already asked it (they did not).
What you'll find in today's issue:
- Why the most requested feature is a symptom, but not a brief
- The eight questions we ask before we agree a problem exists
- The one question that did absolute work in this case
- How to run this on your own roadmap without needing to call us
The suggestion box is stuffed full of imagination
"Most requested" is a list of solutions your customers were able to think of, using the vocabulary they already have, filtered through whichever ones of them bothered to write in.
That is useful information! It is just not a problem statement that enables product strategy or design.
The real thing that mattered in beehiiv's case was underneath the request, and it was actually much more specific once we found it. Their most engaged publishers, the ones with the healthiest businesses, were sending their audiences to Circle, Discord, and Slack.
Every time a reader wanted to talk to another reader, the conversation left the platform, and functionally took the relationship with it.
Read those two sentences next to each other and it is easier to spot the difference.
"Customers want a community feature" gets you a community tab in a sidebar.
"Our best publishers are exporting their most engaged readers to somebody else's product" gets you a strategy, a potential premium tier, a competitive position, and a reason for the whole thing to exist.
Ostensibly, these are the same fact. But in practice, they are a completely different brief.
This shows up in enterprise product strategy constantly, and it isn't always from a customer request. It's from the account that threatened to churn, or from the sales team who lost three deals and can name the feature that would have saved them (marking a deal as "closed lost" and putting the reason as a missing feature is violence against your product team, FYI). These types of requests often show up pre solved and slightly urgent. That combo can be deadly, because people stop asking questions when feature requests show up in that form.
Eight questions that always lead to better product decisions
I always wanted to say this: steal my homework! Here are eight banger questions to make you smarter about adding big, new features to existing products:
1. What problem or need are you actually solving? Not what feature. What is broken today, for whom, and how do you know.
2. How are the needs of the end user different from the needs of the buyer? More on this one below
3. What value do you expect this to deliver, and to whom? Engagement, retention, monetization, feedback loops, competitive defense. Pick. If the answer is all of them, try harder
4. What does this done right look like to you? Ask for reference products by name. What people admire tells you more about their taste and their real ambition than any requirements doc will.
5. What functionality are you even considering? A feed. Threads. Channels. Direct messages. In beehiiv's case, reader to reader, or creator to reader? Both? This is where you find out that two people in the room have been imagining different products
6. How should this fit into the product you already have? Add on, core surface, or separate destination. This question is worth its own issue (and is getting one next week!)
7. How does this line up with company strategy? If nobody can connect it to something leadership already committed to publicly, it will lose its funding in the next planning cycle, no matter how good it is 😢
8. What does success look like at three months and at twelve? These should almost always be different answers. If they are the same answer, nobody has thought about adoption curves
Nothing here is clever or proprietary. That is sort of the point. The main thing is that you actually ask and answer them, because most people just won't
The question that did work work work work (Rihanna voice)
Question two! If I was better at list building, I would have done the "number 2 will blow your mind" thing
So for beehiiv, the buyer is the publisher and the end user is the reader. Their needs are different, and occasionally they point in opposite directions.
A publisher wants control, moderation, and a way to gate access. A reader wants a place that feels alive (it's aliiiiiveeee) and worth checking in on a daily basis.
Design only for the publisher? Admin software nobody visits.
Design only for the reader? Ship something no publisher can safely turn on without huge risk.
And in beehiiv's case - split it again! "The publisher" in this case is two separate, distinct types of users.
A creator with 5,000 subscribers and a media operator with 200,000 subscribers need all kinds of different types of utility.
If you run any kind of platform with a self serve tier and a bigger, noisier, better paying tier above it, you for sure have this fight in your roadmap right now, even if you don't realize it. This tension usually gets resolved by whoever argued most convincingly in the last planning meeting
Most of the genuinely interesting decisions in our work on this with beehiiv trace back to holding both users in frame at once instead of averaging them into a customer who does not actually exist
Try these questions - it's fun, I swear!
Pick the initiative on your roadmap with the most momentum and the least documented reasoning. There is always one, I promise
Answer the eight questions in writing. Give yourself a page. Don't outsource them to Claude.
Three things tend to happen. Sometimes the project survives intact and you now have a business case - yay! Sometimes it survives but changes shape - that's cool too! And sometimes it dies - but it dies quickly and cheaply, which is the best way for a feature to die.
All three are good outcomes, and it only cost you an afternoon of your time.
