Three Good Ideas, One Useful Focus

Three worthwhile ideas can still compete for one focus. Choose around an observable outcome, explain what will wait and say what evidence could change the decision.

7 October 2026 · The Tellenze team

Three folded paper paths extend from a shared square on an ivory tabletop; a teal path ends at a brass marker beside navy and coral alternatives.

The awkward part of choosing a focus is that the ideas you leave behind may be good.

Someone has noticed a real problem. Someone else can see a useful improvement. A third person has a prototype that makes the possibility feel wonderfully close. Nobody has to be wrong for the team to choose just one.

The decision gets easier to explain when you can name the outcome you're pursuing and the evidence that would make you reconsider the alternatives.

Give the ideas something to compete for

Consider a fictional team building booking software for small service businesses. It has three plausible opportunities:

Make the first booking link easier to set up.
Add a calendar integration that existing customers have requested.
Improve the dashboard so owners can understand where appointments come from.

All three could help somebody. The team also has an agent that can prepare implementation options and prototypes. There is plenty to explore.

For this example, suppose the team's immediate goal is to help new trial users publish a working booking link without calling support. Its recent support notes describe people getting stuck while setting their opening hours. The calendar requests come from established customers. The dashboard idea grew from a demonstration where the charts felt unhelpful.

That gives the conversation a useful shape. The setup problem sits directly in the path of the chosen outcome, with evidence the team can inspect. The other ideas address different moments in the customer's work.

The team chooses a focus around the first booking link. It can investigate the opening-hours step, try a clearer flow and check whether new trial users complete it unaided. The decision includes room to discover that the suspected problem is somewhere else.

These are invented circumstances, rather than a Tellenze customer story or measured result. A real team would start by checking its own evidence and agreeing what improvement would be meaningful.

A score can help you ask better questions

Sean McBride's original explanation of RICE at Intercom offers a structured way to compare reach, impact, confidence and effort. It also says the resulting scores need judgment: dependencies or a feature needed to serve certain customers can justify a different order.

The useful part for our booking team is making its assumptions visible. How many new users encounter the setup problem? How confident are we that it prevents a first booking? What work will design, engineering and support have to contribute?

The calendar integration may look attractive because several people have asked for it. That still leaves questions about which customers need it, how much it would change their experience and what maintaining the connection involves.

You can use a scoring method when the inputs are worth comparing. If the inputs are mostly guesses, discuss the guesses. A polished spreadsheet can make uncertainty look settled.

For this small decision, a short comparison is enough:

First booking setup

The support notes point to trouble setting opening hours. Investigate that step and improve it within the selected focus.

Calendar integration

Existing customers have asked for it. Keep the request visible while clarifying its importance for those customers.

Appointment dashboard

A demo raised questions about the charts. Defer the redesign until the owners' actual decisions are better understood.

The comparison exposes an important difference: each idea has a reason to exist, but only one currently has a clear connection to this focus.

Let waiting mean something

A deferred idea can become an awkward sort of promise. The team says “later,” and everyone hears a different date.

Basecamp's Shape Up chapter, Bets, Not Backlogs, takes a deliberately different approach from a growing ranked roadmap. Its betting table considers a small set of potential projects; unselected pitches don't become an automatic queue of obligations. Important ideas can return with fresh interest.

That approach has value even if your team keeps a backlog. An item can remain useful evidence without being a commitment to build it.

In our example, the team writes a concrete note beside each deferred idea. For the calendar connection, it will reconsider when customer conversations clarify a recurring scheduling problem that the integration could solve, or when a confirmed commitment makes it necessary. For the dashboard, it wants to understand which decision an owner struggles to make before proposing new charts.

The notes give the people who raised the ideas somewhere to take new information. They also let the team explain today's choice without pretending that every alternative is unimportant.

A legal, security or reliability obligation may change the available choices altogether. Establish those constraints before comparing optional improvements. An urgent production problem deserves its own response, even if it interrupts a carefully chosen focus.

Faster prototypes still need a choice

AI assistance can make it tempting to start several candidates because the first version of each looks affordable.

The 2025 DORA research overview describes AI as an amplifier of an organization's existing strengths and weaknesses. That is an organization-level finding; it doesn't establish how quickly our fictional team, or any particular agent, can deliver these features.

My practical concern here is what happens after a prototype appears. Someone still has to understand it, try it with users, make decisions about the design and support the result. A lower implementation estimate changes part of that calculation.

An agent can help our team compare the three opportunities, gather accessible evidence or prepare a narrow experiment. The owner of the outcome can then decide where the team will spend its attention. Starting all three would also be a decision, with consequences worth discussing.

Parallel work can be sensible when the outcomes and capacity support it. In this example, the team has chosen one immediate outcome and can explain why the other opportunities will wait.

Leave a decision the team can use

The Loop guide to focuses describes organizing work around an outcome, with a rhythm suited to the work. A focus gives this booking team a place to connect its investigation, changes and checks. The Tellenze work-item guide explains where the team can retain the definition, discussion and evidence.

You can make the same decision visible with your existing board and a shared document. Before starting, write a short note:

Outcome: New trial users can publish their first booking link without support.

Chosen work: Investigate the opening-hours step and test a clearer setup flow.

Deferred work: Calendar integration and dashboard redesign.

Reason: The current setup evidence connects most directly to the intended outcome.

Reconsider when: New evidence changes that connection, a confirmed obligation alters the priorities, or the focus review gives us a better next choice.

The note can change as the team learns. If research shows that trial users understand the opening-hours screen and are actually confused about publishing, the focus can follow that evidence.

The person who suggested the calendar integration still has a useful idea. Today, they also have an explanation for why the team is working on something else.