How a Yakima Steelhead Guide Became Our Most Active Feature Requester

The first message

The first message from M. came in before dawn — 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 note became the seed of a relationship that’s now reshaped a meaningful slice of the product. We replied with a few follow-up questions. He answered all of them before lunch. We shipped the fix a couple of weeks later, while he was on the water.

What a prolific requester actually looks like

Idea after idea, 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. Many have shipped. Others sit in the in-app Development Queue, where anyone can see and vote on what’s coming next. A few we’ve declined, with a reason. 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 message 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 — took us a few 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 write it up.

The trust premium that builds over time

The first request we shipped, we shipped quietly. The next, we sent him a screenshot the night before it went live. Before long he was getting builds before the public did and telling us, in detail, what was wrong with our spacing. Eventually he started forwarding the ideas 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 more than once. Sometimes because a request would have required scraping a state agency’s data in a way that would’ve gotten us sued. Sometimes because the feature would only have served a sliver of guides on one specific tailwater and the maintenance burden was permanent. Sometimes 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. It’s the reason we made the Development Queue visible in the app: you can watch where your idea sits and where it’s headed.

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 that many good requests 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 feedback, 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 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 a handful of the right ones, and you need to be willing to pick up the phone, or the feedback note, at hours that would horrify a venture-backed product team. M. is one of a small group of founding members 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 messages you from a truck cab before dawn is handing you the roadmap, free of charge, before the competition has even noticed there’s a problem.

If you want to shape the app this way, you don’t apply. Use the app, send the request, and watch the Development Queue.