Voice Memo to Production: How We Ship Features in Under Two Weeks

Most apps treat feature requests like compost. You drop a suggestion into a form, it disappears into a backlog, and eighteen months later a sanitized version of your idea ships next to a press release about “listening to our community.”

We don’t do that. We can’t, really — the people sending requests are usually standing in a river, looking at a screen, watching something we built fail to tell them what they needed. The feedback loop has to be short or the app stops being useful.

Here’s the six-step lifecycle, exactly as it runs.

Step 1: The voice memo arrives

Most requests come in as voice memos. Someone on a bank, on a logging road, in a parking lot waiting for the rain to ease. Forty-five seconds, often unedited. “Hey, the gauge is showing CFS but I think in feet for this section, can we toggle that?” That one became the CFS/gauge-feet toggle. Two days end to end.

Step 2: Triage in hours

Requests land in a feedback queue the team reviews daily. Triage is fast and unromantic — three buckets: ship now, ship soon, needs more thought. Emergency rule notifications were a “ship now” because a user was watching a closure go live with no in-app warning. We had a working version that week. No meeting. No ticket template. No Jira.

Step 3: Clarify the actual problem

This is where most product processes fail and most of ours succeed. Before scoping, we go back to the requester. “When you said turbidity, did you mean the NTU number or just a ‘is the water blown out’ read?” The answer is almost always the second thing. So we shipped a turbidity read, not a turbidity dashboard. Smaller surface, faster ship, same value.

Step 4: Scope the smallest viable shape

Every feature has a maximalist version and a minimum version. We almost always ship the minimum first. When users asked for Celsius, the maximalist version was a full unit-preferences system with imperial/metric toggles across the app. The minimum was a Celsius display next to Fahrenheit on the temperature readouts. We shipped the minimum in three days. The full system is still queued — nobody’s asked for it twice.

Step 5: Ship it

Engineering work happens in tight increments — usually one to three days for a smaller feature, up to two weeks for something larger. Adding the Niagara River to the catalog took a single afternoon. Hatchery alerts — pulling release data, building the notification path, designing the in-app card — took eight days. The team doesn’t estimate. We just start, and if a feature drags past two weeks, we stop and ask whether we scoped the wrong shape.

Step 6: Tell the requester first

When a feature ships, the person who asked for it hears about it before anyone else. Not a marketing email. A direct note: “Hey, your turbidity request is live in the update going out tonight. Let me know if it’s not quite what you meant.” Then it moves to “shipped” in the in-app Development Queue, where every other user can see it. The whole arc — voice memo to “it’s live” — usually closes in under two weeks.

Where the process fails

It fails when the request is actually a wish for someone else’s app. Someone wants a social feed, a leaderboard, a friends list, a way to share their catch. We say no, and we say it directly — those aren’t in scope, and pretending otherwise wastes everyone’s time. It also fails when we scope wrong and have to rebuild. The first version of hatchery alerts shipped without filtering by user location, which made it noise for anyone outside the regions we had data for. We rebuilt it in the following week with proper geography filtering. Failing fast is cheaper than failing slow, and admitting the failure publicly in the Development Queue is cheaper than quietly fixing it and hoping nobody noticed.

Why we don’t run sprints

We tried, briefly. Sprints make sense when you have a roadmap nobody is allowed to interrupt. Our roadmap gets interrupted by definition — that’s the point. A two-week sprint with a locked scope means a voice memo on day one of the sprint sits for thirteen days before anyone touches it. That’s not a feedback loop, that’s a delay loop. We work in continuous increments instead. The closest thing to a “sprint goal” is the in-app Development Queue, which is just the next five-to-eight things in priority order, visible to every user.

The Founder veto

Founders — the early users who backed the app before we knew if it would work — get a heads-up before any design change ships. Not a vote. A heads-up, usually with a screenshot, sometimes 48 hours ahead. Most of the time the response is a thumbs-up emoji. Occasionally someone says “this hides the gauge reading on the small phones,” or “the new color makes the turbidity warning blend into the background at dusk,” and we adjust before shipping. It’s a sanity check from the people who use the app hardest, in the worst conditions, and it’s caught more than one regression that would have shipped to everyone otherwise.

That’s the entire process. There’s no committee. There’s no quarterly planning offsite. There’s no product manager translating user needs into feature specs and back again — the loop is short because the translation layer is gone. The team triages, clarifies, scopes, ships, tells the requester, moves on.

The reason we can run this lean is that the surface area of the app is intentional. We don’t try to be everything to everyone. We’re a maps and conditions app for people who go outside in the Pacific Northwest. When a request comes in that fits that scope, we move fast. When it doesn’t, we explain why not. That clarity at the edges is what makes the inside move quickly.

People sometimes ask if this is sustainable as the user base grows. The honest answer is: we don’t know yet, but the math is friendlier than it looks. Most requests are duplicates — twenty users asking for the same toggle counts as one feature. A surprising number of requests are bug reports that look like feature requests, which means triaging well turns “build me a thing” into “fix the thing you already built.” The actual queue of net-new features stays manageable, somewhere between five and fifteen items at any given time, and most of those are smaller than they look on first read.

The other thing that keeps the loop short is that we don’t pretend ideas are finished products. A voice memo is an idea. A clarifying reply is a sharpened idea. A scoped shape is the cheapest version of that idea worth shipping. The full version, if it ever comes, is built on top of what’s already in production with real users hitting it. Most of the time we never need the full version — the minimum is enough, and the next request points us somewhere we didn’t expect.

The Niagara River addition is a good example of how unromantic this can be. A user wrote in: “Any chance you can add the Niagara? I fish it twice a week.” The team checked the data source, confirmed the gauge feed was available, added the river to the catalog, tested it on staging, and shipped it in a single workday. The user got a note the next morning. Nobody held a planning session. Nobody wrote a PRD. Nobody scheduled a kickoff. The whole cycle was maybe four hours of work spread across two people, and the requester’s response was a single line: “Holy crap, that was fast.” That response, more than any metric, is what we’re optimizing for.

That’s the version of “moving fast” that actually works for software people use outside, in weather, with cold hands. Not the move-fast-and-break-things version. The move-fast-because-the-loop-is-short version. Triage in hours. Clarify before scoping. Scope the smallest shape. Ship in increments. Tell the requester first. Repeat.

If you want to see what’s in flight, the Development Queue is in the app — Settings → Development Queue.