How Taciturn Studios Picks Which Products to Ship

Every small studio has more ideas than hours. A book series that could become a companion app, a calculator that could become a site, a tool built for one author that might help a thousand. The hard part is rarely having ideas. It's choosing which few deserve to be finished, launched and maintained for years, and which should stay in the notebook.

This is the filter we use at Taciturn Studios. It isn't a formula, and we don't always get it right, but writing it down keeps us honest when a shiny idea shows up on a Tuesday afternoon.

The three questions every idea has to answer

Before anything gets built past a sketch, it has to give a plain answer to three questions. If any answer is fuzzy, the idea waits.

1. Who is the user, specifically?

"Authors" isn't a user. "Self-published authors who run their own Amazon ads and lose track of which keywords are wasting money" is a user. The narrower the description, the easier it is to know whether the product is working, where to find the first people who need it, and what to leave out.

This is close to the "jobs to be done" idea that Clayton Christensen and colleagues described in their 2016 Harvard Business Review article, "Know Your Customers' 'Jobs to Be Done.'" Their argument was that people don't buy products for their features; they "hire" them to make progress in a specific circumstance. We try to write the job in one sentence: When I'm doing X, I want to Y, so I can Z. If we can't, we don't understand the user yet.

2. How does it pay for itself?

We're a small independent studio, so every product has to have a believable path to covering its own costs. That might be a book sale, a subscription, a one-time license, advertising on a genuinely useful content site, or an affiliate relationship that we'd be comfortable disclosing. What it can't be is "we'll figure out monetization once it's popular." Popular-but-unfunded products quietly consume the time that funded ones need.

The path doesn't have to be large. A small tool that reliably earns a modest amount and costs almost nothing to run can be a better product than an ambitious one with no clear revenue.

3. What will it cost to keep alive?

This is the question most people skip, and the one we weigh most heavily. Building something is a one-time cost. Maintaining it is forever: dependency updates, hosting, security patches, policy changes on platforms it relies on, customer emails, broken integrations when a third-party service changes its API.

Before we build, we try to list:

• Which external services it depends on, and how likely they are to change.
• What happens if we don't touch it for three months.
• Who answers when something breaks.
• Whether it needs fresh content or data on a schedule.

A product that degrades gracefully when ignored is worth far more to a small team than one that needs weekly attention to stay functional.

Useful beats clever

The ideas that excite builders most are often the cleverest: novel interfaces, impressive technology, unusual combinations. The products that last tend to be plainer. They remove a recurring annoyance, answer a question people actually search for, or make a tedious task faster.

We use a simple test: Could we explain what this does to the user in one sentence, without using the word "platform"? If the explanation needs a diagram, the product may be solving a problem we find interesting rather than one the user has.

Paul Graham's 2013 essay "Do Things That Don't Scale" makes a related point from the startup world: early on, doing manual, unglamorous work for a handful of users teaches you what they actually need. For us, that often means helping one author by hand before deciding whether a tool is worth building at all.

Signals that push an idea forward

Some signals make us more likely to commit:

• We've already done the job manually several times. If we keep solving the same problem with spreadsheets and scripts, a product may be hiding in that repetition.
• People ask for it without being prompted. Unsolicited requests are better evidence than enthusiastic responses to a pitch.
• It fits an existing audience. A tool for authors fits naturally alongside our books and author resources. A product for an unrelated audience has to build trust from zero.
• It can launch small. If a useful first version can ship in weeks rather than months, we can learn from real use quickly.

Signals that make us wait

• The idea depends on a platform policy that could change overnight. Products built entirely on one company's goodwill carry risk we can't control.
• It requires constant fresh content to stay valuable. Content can be wonderful, but if a product dies the moment we stop feeding it, we treat it as an ongoing commitment, not a launch.
• The main appeal is that it's fun to build. That's a fine reason for a weekend experiment, not for a product with a maintenance burden.
• We can't name the first ten users. If we don't know where they are, launching will be guesswork.

Shaping before building

Once an idea passes the filter, we decide how much time it deserves before we start. Ryan Singer's Shape Up (Basecamp, 2019) calls this setting an "appetite": instead of estimating how long a full vision will take, you decide how much time the problem is worth and shape a solution that fits.

A fixed appetite protects small teams from the slow creep that turns a two-week tool into a six-month project. If the first version can't fit the appetite, we cut scope rather than extend the deadline.

After launch: keep, fix or retire

Shipping isn't the end of the decision. Every product we run gets revisited periodically with the same questions: Is anyone using it? Is it paying for itself? Is the maintenance cost still reasonable? We write about what we watch in Measuring Fleet Health Beyond Vanity Traffic, and about how we shut things down responsibly in When to Kill a Side Project Cleanly.

Why we share this

Many of the authors and makers who visit Taciturn Studios face the same problem at a different scale: too many book ideas, too many marketing channels, too many tools to try. The same three questions apply. Who exactly is this for? How will it sustain itself? What will it cost to keep going?

If you're weighing your own projects, our posts on building small software for specific jobs and the indie author tools we actually use go deeper into the practical side. You can also browse the Taciturn library to see where those choices have led for our own books.