Find the wedge, then narrow it again

We spent months exploring the wrong half of our product. Our customers corrected us in one sentence.

Here is the story, because the lesson only makes sense if you see how we got there. (The shorter case study version, with the artifacts, lives here: Finding the wedge.)

The market was huge, and that was the problem

We were building in software management. The full vision was big. Help a company see its software spend, provision new hires into the right tools, and deprovision people when they leave. Spend, access, the whole thing.

A big map looks like opportunity. It is actually a trap. When everything is in scope, you have no reason to pick, and a small team that does not pick does not ship.

I had a bias going in that turned out to be right. Early on I wrote to the team that software used to be made for a specific person, like KidPix, and that we had drifted into making things that appeal to everyone instead of a very specific customer. I believed we were heading back toward specificity. So even while the vision was broad, I kept pushing one idea. Start with one group of customers, get really good at serving them, and scale as they grow.

We did the real discovery work

We did not guess our way to the product. We ran a proper Jobs to Be Done process. I grouped stickies on a board around the jobs a customer was actually trying to get done, then mapped what we wanted them to feel once that job was solved, and only then what the product should do to create that feeling. Jobs first. Feelings second. Features last.

We explored both paths seriously. I spent real time mapping provisioning end to end. I worked out what provisioning even was, where the pain points sat, and the key flows a solution could use. I did not want to narrow the company out of laziness. I wanted to narrow it out of evidence.

So we shipped a slice and put it in front of people. We let them onboard and land on a spend overview. And then we listened.

The one sentence that decided it

The signal came back fast and it was not subtle. In a customer meeting, our notes read, “The spend piece is what is resonating with them. The IT piece is a bit out of scope.” Another customer told us their real headache was just getting devices deployed, which sat even before the provisioning work we had been mapping.

There it was. We had been treating spend as step one of a bigger product. It was not step one. It was the product.

Users cared about seeing their spend. The access and IT work we had planned was, in their words, out of scope. So we made a decision. We narrowed the entire company onto spend. We stepped back from the heavier integrations and provisioning build that nobody had actually asked us for.

That is a hard thing to do when you have already invested time mapping the other path. You feel like you are throwing work away. But the work was not wasted. The work is what told us where not to go.

The idea that gave me conviction

Around this time I was reading The Cold Start Problem, and one story stuck with me enough that I wrote it in a standup. When Bank of America first spread credit cards, they did not launch everywhere. They picked Fresno, because they already had close to half the town as customers. They learned what worked in one concentrated place, then expanded outward slowly until they had the whole state.

The lesson I pulled for us was simple. Even inside your target segment, there is a smaller group who feels the pain hardest. You can always narrow again. Find that group. Build the easiest thing that genuinely helps them. Then let their reaction tell you what your company actually is.

That is the part people skip. They pick a wedge once and treat it as settled. The wedge is not a one time decision. It is a habit of narrowing every time the evidence lets you.

Where I land

You do not pick the wedge that looks most impressive on a roadmap. You pick the one that is easiest to ship and closest to a real, narrow customer. Then you hold it loosely enough that the customer can move you.

We thought we were building spend, access, and IT. The customers told us we were building one screen. So we became that screen, and we got a lot less confused about what to do next.

What did your earliest users actually reach for? In my experience, that is almost always the answer, and it is usually narrower than the thing you set out to build.