How a Yakima Steelhead Guide Became Our Most Active Feature Requester

The first voice memo

The first message from M. came in at 4:47 a.m. on a Tuesday in March. Forty-one seconds, recorded from a truck cab somewhere outside Cle Elum, engine idling in the background, the sound of a thermos lid being unscrewed. “Hey, love the app, one thing — when I’m reading the Yakima I think in gauge feet, not CFS, and I’m pretty sure I’m the only guide in the state who toggles a calculator open every morning. Can you fix that?” That voice memo became the seed of a relationship that’s now reshaped a meaningful slice of the product. We replied at 7 a.m. with three follow-up questions. He answered all of them before lunch. We shipped the fix nineteen days later, on a Saturday, while he was on the water.

What 47 requests in a year actually looks like

Forty-seven voice memos and texts, averaging just under one a week, almost all sent before sunrise. They’re never polite. They’re never long. M. tells us what’s missing, what’s wrong, what a client asked about on the drift, what would have saved twenty minutes of fumbling at the takeout. Twenty-eight have shipped. Eleven are in the in-app Development Queue. Six we declined, with a reason. Two were duplicates of his own earlier requests, which he found funny. The cadence isn’t random either — it spikes around openers, around weather swings, around the weekend before a tournament when his clients start texting him about flows. Volume tracks the river, not the calendar.

Examples of what M. shipped

The per-river CFS-versus-gauge-feet toggle came from that first memo and now lives on every river page in Washington. The emergency-rule push notifications — the ones that fire when a state agency drops a hoot-owl or a closure — were entirely his idea after he watched a client unknowingly fish a closed section and spend the rest of the day apologizing on the phone to a warden. Turbidity readings on the gauge cards came from a single line: “I can tell you the flow but I can’t tell you if it’s chocolate milk.” The text-message-friendly flow chart share — the one that renders cleanly when a guide pastes it into a client thread — that was request number nineteen, and it took us four tries to get the dimensions right before he stopped sending us screenshots of how it looked broken on his clients’ Android phones.

Why the requests are better than internal ideas

Internal product ideas are almost always one of two things: a feature we think looks good in a screenshot, or a feature that solves a problem we’ve imagined a user might have. M.’s requests are neither. They are problems he hit that morning, in real water, with real clients in the boat asking real questions. There is no abstraction layer between the friction and the request. That’s a quality of signal you cannot manufacture from a whiteboard, no matter how many personas you tape to the wall. And the requests carry context internal ideas almost never do — what the weather was doing, what the client was asking, what the existing workaround looked like, why this morning was the morning he finally got annoyed enough to record a memo about it.

The trust premium that builds over time

The first request we shipped, we shipped quietly. The second, we texted him a screenshot the night before it went live. By the tenth, he was getting builds before the public did and telling us, in detail, what was wrong with our spacing. Somewhere around request twenty he started forwarding the voice memos of his guide friends, prefaced with “this guy doesn’t know you exist but he’s right.” That’s the trust premium. It compounds. It’s also non-transferable: you cannot buy it, advertise into it, or pitch-deck your way to it. The only way to earn the next request is to ship the previous one well, and then to tell the requester exactly what changed.

When we say no (and how)

We’ve said no six times. Once because the request would have required scraping a state agency’s data in a way that would’ve gotten us sued. Twice because the feature would only have served a sliver of guides on one specific tailwater and the maintenance burden was permanent. Three times because what M. actually wanted, once we dug in, was a workflow change rather than a feature — and we sent him a two-minute screen recording showing the existing path. Every no comes with a reason. None of them have cost us the relationship. The trick, we’ve learned, is that “no” is fine when “no because” is honest. What kills trust is the silent backlog, the request that vanishes into a form and never resurfaces. Guides know when they’re being managed. They can smell it through a screen.

What this teaches about building in public

Building in public is mostly described as a marketing tactic — post the metric, share the screenshot, narrate the journey. That’s the shallow version. The deeper version is that the product itself becomes a conversation, and the people on the other end of the conversation are not your followers, they’re your collaborators. M. has never tweeted about us. He has, however, changed the shape of the app more than any internal planning document we’ve ever written. The in-app Development Queue exists because of him — because once you’re getting forty-seven good requests a year from one person, you owe everyone visibility into what’s queued and what’s coming. The roadmap isn’t a marketing artifact anymore. It’s a receipt.

We get asked, often, how we decide what to build next. The honest answer is that we read the voice memos, we sort by frequency and severity, we weigh what’s technically reasonable against what would meaningfully change a morning on the water, and we ship. The unsexy truth of community-driven product is that it requires you to actually listen — not in the performative “we hear you” sense, but in the boring operational sense of having a tagged inbox, a triage cadence, and a willingness to be told you’re wrong by someone who knows the river better than you do.

The thing we didn’t anticipate, when we started building this way, is how much it would change our internal culture. We stopped having ideation meetings. We started having request-review meetings. The question went from “what should we build” to “which of these forty-seven things will move the needle for the people already using us.” That’s a fundamentally different muscle. It’s also, we think, the right one for a small team building tools for a specific kind of person doing a specific kind of work outside.

If you’re building something for a niche — and steelhead guiding in Washington is a niche inside a niche inside a niche — you don’t need a thousand users to know what to build. You need ten of the right ones, and you need to be willing to pick up the phone, or the voice memo, at hours that would horrify a venture-backed product team. M. is one of about a dozen Founders who shape the product this way. He’s the most prolific, but he is not unique in kind. He’s just unique in volume.

The advice we’d give any founder of any small software company is this: find the person who is angrier than anyone else about your product’s gaps, and treat their anger as the most valuable input you will ever receive. The customer who churns silently teaches you nothing. The customer who voice-memos you from a truck cab at 4:47 a.m. is handing you the roadmap, free of charge, before the competition has even noticed there’s a problem.

If you want to become a Founder, you don’t apply. Use the app, send the voice memo, and watch the Development Queue.