Three weeks before our biggest demo, we’d sat in a conference room learning how this customer’s purchasing team worked. One step in their process required confirming technical specifications with an internal engineer before a quote request could go out. The details varied by material category, but the pattern was the same everywhere: critical information lived in people’s heads, passed along in hallway conversations and phone calls. No system tracked any of it. No database. No form.
So we built one. An inquiry workflow that routes the question to the right engineer, captures the answer, and feeds it into the quote request automatically. By the time we showed up for the 72-minute demo, it was already working.
Midway through, the buyer paused. “That information isn’t documented anywhere yet,” he said. “It’s all just word of mouth.”
“Yes, we heard that. So we made it.”
His face changed. That small moment, answering a question the customer didn’t expect us to have thought about, is what this post is about. But it took a long time, and a misreading of a famous document, to get there.
Two kinds of “spread”
In 2006, Yahoo executive Brad Garlinghouse wrote an internal memo that became known as the Peanut Butter Manifesto. Yahoo was spreading resources across too many businesses, thinly, like peanut butter across an entire slice of bread. Every initiative got a little attention. None got enough. His prescription: focus. Pick where you can win, and concentrate there.
We believed him. Built our product accordingly.
Took years of talking to customers before we realized we’d confused two different kinds of breadth.
The first is business breadth: how many markets you serve, how many customer segments you chase. Spread yourself across too many and your product becomes incoherent. Nobody can tell who it’s for. On this point, the Manifesto is right. One buyer we spoke with dismissed a major SaaS platform in exactly these terms: good at a lot of things, not very good at any of them.
The second is workflow coverage: how much of a customer’s job your product actually handles, start to finish.
This is where we went wrong. We treated the Manifesto’s lesson as if it applied here too. Narrow down. Go deep on one capability. Make it exceptional.
Customers weren’t buying a single exceptional capability. They needed a product that let them finish their work without stopping halfway to open a spreadsheet.
A single feature doesn’t finish the job
At one company, we estimated that automating a single routine task (generating and sending purchase orders) could eliminate 70–90% of the manual effort. Sounds like a meaningful improvement. But the math: the time saved amounted to 0.04–0.14 of a full-time employee per year.
Useful, maybe. Not enough to justify buying a product.
One step gets faster, but the steps before and after it still require spreadsheets and email. The job as a whole doesn’t get much easier. The unit that matters to customers isn’t a feature; it’s the workflow, the full sequence of tasks from start to finish. A product covering only one slice of that sequence, no matter how well, solves a fraction of the problem.
We’d started by spreading jam on the crust of the bread. Interesting, maybe even unique. But nobody buying a sandwich is looking for better-tasting crusts.
What we should have focused on was a specific customer’s specific workflow. Not a single function.
Narrow the business. Cover the chosen workflow edge to edge.
“Yes, we have that,” and how it grows
You can’t understand a customer’s entire workflow from the start. Obviously. We began with a core product and showed it to as many prospects as we could.
Every demo surfaced new questions.
- “Can we import our own Excel templates directly?”
- “Can we compare multiple candidates side by side?”
- “If a conversation continues over email outside the platform, can that get captured back into the record?”
In the beginning, our most common answer was “not yet.”
We took those questions back. Asked ourselves where, in the customer’s workflow, our product broke. Where they’d have to leave and go back to email or a spreadsheet. If the same gap showed up across multiple customers, and closing it was necessary to let the work flow from start to finish, we built it.
Then we demoed again. Questions that used to get “not yet” started getting a different answer.
“Yes, we support that.”
The cycle repeated.
The workflow from the opening of this post came from exactly this process. One customer told us about an undocumented, verbal-only step in their process. We built the mechanism. When a different customer asked about a similar case weeks later, it was already there.
This wasn’t about saying yes to everything. A one-off requirement unique to a single organization would spread the product thin again, right back into the trap the Manifesto warns about. The filter was always: does this gap appear across multiple customers, and is it necessary to complete the workflow we chose to cover?
What happens when “yes” comes up several times in one meeting
A customer raises a specific case. The answer is “yes, we handle that.” Once in a meeting, it registers as a feature check.
Three or four times in the same meeting, something shifts.
It stops being a list of features. It starts looking like evidence. Evidence that the people across the table have already seen the situations this customer deals with, and studied the work closely enough to anticipate cases the customer assumed they’d have to explain from scratch.
One buyer did put it into words, though not the ones we expected. “You’re not from purchasing,” he said. “How do you know what we care about?” That question, asked with genuine surprise, told us more than any praise would have. He wasn’t complimenting the product. He was trying to figure out how outsiders had mapped his problems before he’d explained them.
Feature coverage isn’t about making a feature list longer. It’s about accumulating lessons from many customers so the next customer’s work doesn’t get stranded halfway through.
Narrow the bread. Spread to the edges.
Narrow the business. Garlinghouse was right. Pick one customer segment, one problem space, and commit. Finding our slice took longer than we’d like to admit.
Don’t confuse the unit of bread. In the world of features, a slice of bread is one customer’s workflow, start to finish. A single feature isn’t a slice. It’s a crumb. An improvement worth 0.04 of a full-time employee, however polished, doesn’t get bought.
Cover edge to edge. Walk the customer’s actual screens and actual files, step by step. Mark every point where they leave your product for a spreadsheet or an email. Those are the edges. The steps running on word of mouth and undocumented knowledge are edges too, and they only surface when you’re close enough to see the work as it actually happens.
Keep listening. Not every request belongs in the product. But every “not yet” is a data point. If the same gap comes up across customers and it sits in the workflow you chose to own, close it. Your inventory of “yes, we have that” grows only as fast as you listen.
Yesterday’s “not yet” becomes tomorrow’s “yes, we have that.” That is the work.