I did not design the roadmap

The product I sell now was not designed. It was excavated, one complaint at a time, by people who had no idea they were doing it.

Here is the actual sequence.

Three versions of a newsletter

The first idea was a weekly newsletter: five opportunities, drawn from across the utility market, sent to vendors who sell into it.

That became a newsletter about five opportunities at a single utility, which is a smaller and stranger thing to send someone.

And that became the utility profile — the same five opportunities, but as a document about one organization rather than a bulletin. At which point it stopped being a newsletter at all, and the newsletter never launched.

Three versions, and the only thing that survived from the first was the number five.

Then I started sending it to people

This is the part that did the work. I sent profiles to prospects, got on calls, and asked what they thought.

They told me. And because I was showing them something concrete rather than describing an idea, what came back was not encouragement — it was requests. More features. Different cuts. Things they wished it did.

Some of it was already on my roadmap. Some was already built. But a good deal of it was new, and I wrote it all down immediately.

I should be honest about the state I was in during those months, because from the outside it looks like a plan being executed. It was not. There were a lot of conversations and a lot of interest, and it was still not clear what exactly the product was. That is an uncomfortable thing to sit in for weeks while sounding confident on calls.

Every feature, and the complaint that produced it

Looking back, I can trace each piece to something a customer said.

A screener, and then AI search. People wanted to slice the market by things no report contains. Not population — everyone has population. How many miles of pipeline. What kind of meters. Whether the utility has signaled any intent to deal with PFAS. Once you want to filter on facts that only exist buried in documents, you are no longer building a filter. You are building search over things nobody has structured yet.

Ongoing monitoring. A profile is a good baseline and it is static. The utility keeps having meetings after I hand you the document. So the profile had to stop being a document and start being a position that updates.

A chat agent. Customers kept coming back with follow-up questions — sharper than the ones I had anticipated, because they knew their own business. They did not want a better report. They wanted to interrogate the one they had.

An actions layer. This one came from thinking a step ahead about our own feature. If monitoring works, it produces alerts, and a salesperson buried in notifications will ignore all of them within a fortnight. So every alert has to resolve into specific actions for sales and marketing, which someone can then assign and own. Otherwise you have built a very sophisticated way of being ignored.

And one deliberate refusal: we are not the CRM. Every one of those decisions needs to be recorded somewhere, and there was an obvious temptation to become the place where it is recorded. We decided early not to. We integrate with the CRM and let it stay the system of record. It is a smaller product that way, and a much easier one to adopt.

None of that was foresight. It is what happens if you put a real artifact in front of people and then listen properly to what annoys them about it.

Two more products, which looks like the old mistake

While all of that was going on, I started two other things.

One was an events app, for the offline half of the job. The logic: everything the main product does is online intelligence, but sales in this sector happens at conferences, where a great deal of context is generated and almost none of it survives. You are three days into an event, you have had forty conversations, and by the following week most of it is gone. So — discover which water events matter, prepare properly for the ones you attend, see who is speaking and whether anyone you are tracking will be there, take notes in the moment and have them become pipeline actions afterwards. We engaged an agency to build it.

The other was automating permit applications for an engineering consulting firm in the water sector. A real problem, and a completely separate product.

Four months after deleting almost everything I had built, I was building two more things. On the surface that is precisely the behavior that got me into trouble the first time, and I want to be careful not to let myself off lightly.

But it is not the same, and the difference turns out to be the useful part.

The events app is built. The first version is ready to publish on both app stores, it has been tested with multiple customers, and they want it. What remains is seeding the event data, a beta group, and their feedback. It is adjacent and complementary to the main product rather than another module inside a platform nobody had yet bought.

The permit product was built for a specific customer, who has given good feedback, and it is close to shipping. It can produce revenue now, which bootstraps the company. And the engine underneath it extends directly into prefilling RFPs — which is the main product's own direction, since the entire thesis is being present before the RFP exists.

So: in May 2025 I built modules because I could imagine somebody wanting them. In 2026 I built two things because somebody specifically did, and each has a route back — one to the core product, one to the bank account.

That is the whole distinction, and it is not about restraint.

What I would take from it

Do not write the roadmap in a room. Write the smallest real thing you can hand to someone, hand it over, and then write down what they complain about. The complaints arrive in order of importance, which is more than can be said for most planning processes.

And be careful which lesson you take from your own failures. For a while I thought the moral of the teardown was build less — that the error had been ambition, and the corrective was restraint. That is the obvious reading and it is wrong. Two of the things I started in the months right after it would fail a build-less test, and both were correct.

The error was never the number of things. It was building what I could imagine someone wanting. The test that actually separates the two is narrow and unglamorous: did a specific person ask for this, and does it come back — to the product, or to the revenue. Everything I deleted failed that test. What I have kept since, including the parts that look like sprawl, passes it.