An Introduction to the Focus Flow

Why use the Focus Flow?

Agile is the dominant software development method. However, Agile only focuses on how to build, not what to build. The whole process starts with the idea that the product owner has prioritized the backlog. Yet, backlog prioritization is the missing first half of the Agile process.

The Focus Flow is based on the idea that priority is feedback driven. Companies discover priority from mining feedback from customers and coworkers. Feedback includes feature requests, complaints, breaking news, and other ideas. Generally, the process is:

1. Gather feedback from customers and coworkers
2. Group it into topics
3. Decide what you’re going to do about the topics: solve them, research them more, or ignore them
4. Anything you plan to solve, you come up dev ideas
5. You compare dev ideas and choose what you’re going to build next

It works in harmony with company priorities in two ways:

• By generating feedback driven dev ideas that align with the company’s top down goals
• Uncovering emergent risks and opportunities that company goals may have missed

The Flow

A Flow is the full sequence of events for processing feedback into dev ideas. Ideally, this sequence is something that a team does rapidly enough to stay on top of feedback, while still allowing time for developing it into dev ideas. Two weeks is a good time period to start with. 

Starting the Flow [Product Manager Work]

To start the Flow, group all feedback into topics. It’s important to process all new feedback every Flow into topics, otherwise it could build up to unmanageable levels and obscure important product improvements. For some companies, the feedback volume may be easy to process. For companies with a lot of feedback, they may need to have multiple people coordinating to process all feedback.

Grouping into Topics

A topic is a related group of feedback. It can be confusing at first on how to decide which feedback to group together, what to call the group, and how to describe the feedback. When customers and coworkers are providing feedback, it generally comes in four levels:

• Feature request - When someone asks for an outcome or specific solution 
  • Example piece of feedback: I want faster horses
  • Example topic: Faster horses
• Cause - A conclusion about the root problem
  • Example piece of feedback: My horse is too slow
  • Example topic: Horses are too slow
• Issue - An issue is a portion of the root problem.
  • Example piece of feedback: It takes too long to get to town
  • Example topic: Trip to town too long
• Root problem - The lowest level of the problem with all or most of the context
  • Example piece of feedback: My income is limited because I produce milk and can’t deliver it to more customers before it spoils
  • Example topic: Milk spoilage limits distribution income

To minimize the cognitive load and process feedback into topics quickly, it helps to group feedback into topics at the same level. Later, if multiple topics from various levels point to the same solution, they can be grouped by attaching them to the same dev idea.

Topic Decision [Team Meeting]

Deciding what to do about the feedback topics is a team effort. Meeting participants should be as cross-functional as possible to get a holistic view that informs the decision making. Excluding the product manager, ideally there are five to seven stakeholders each from a different department or functional area. Commonly this means making sure to have participants from customer support, sales/marketing, and engineering.

The product manager will select the list of topics. Generally, the approach to topic selection should be:

• New topics
  • If there are more new topics than the team would have time to discuss, then priority should be given to topics that have high customer need and the most feedback. Some companies may also want to give preference to topics from key customers.
• Evaluation topics
  • If any evaluation has completed for a topic, it’s time to pull it into the Flow and decide whether to Solve or Ignore it.
• Ignore topics
  • If the reason for ignoring a topic has changed, it should be pulled into the Flow to decide whether or not to Research, Solve, or continue Ignoring it.

In the Topic Decision meeting, the product manager will take the team through the list of topics one by one. For each topic, the team will decide one of the following outcomes:

• Evaluate
  • Deciding to Evaluate a topic means the team feels uncertain about whether to Ignore or Solve it. Evaluation can be either passive or active. Passive evaluation means the team wants to wait for more information to emerge on it’s own, such as more feedback to naturally come in that applies to the topic. Active evaluation is when the team has specific questions that they want to have answered. When deciding to evaluate a topic, the product manager should capture whether it’s passive evaluation or active. If it’s active, the product manager should capture the team’s questions in the topic description.
• Ignore
  • Deciding to Ignore a topic means that the team knows they aren’t going to do anything about it anytime soon. Teams can feel uncomfortable choosing this topic at first, but without saying no to some topics, there may not be enough resources for other topics. It’s important to be honest about what the team’s intentions are so expectations can be properly set for customers and coworkers. Anything marked as Ignore should include a reason for why it’s being ignored. 
• Solve
  • Deciding to Solve a topic means the team feels clear that the topic should be promoted into a dev idea. Not all topics that are selected to be solved will become a shipped feature, because they need to make it through one more level of prioritization. 

A good amount of time to allocate to the Topic Decision meeting is 30 to 60 minutes. It’s important that the meeting is long enough to conclude on the topics with the most feedback, highest customer need, and key customers. Teams with lots of feedback are most likely to have a long tail of topics with only a single piece of feedback. To speed up meetings, they may want to adopt rules like:

• Automatically ignore topics with only a single piece of feedback that isn’t a key customer.
• Automatically research topics with only a single piece of feedback that is a key customer.

Shaping Dev Ideas [Product Manager Work]

Dev Ideas start with a summary of the feedback in the form of a problem statement and a high-level description of the solution. They should not be in-depth product specifications with high fidelity mockups. They should have just enough detail to allow the team to roughly estimate the potential value and effort.

Attaching Feedback

To provide context, attach all relevant topics to the dev idea. This will make it easy to trace anything that ships all the way back to the people who provided the original feedback. It also allows anyone who is editing or reading the dev idea to look back at what was said.

Crafting a Problem Statement

A problem statement serves as the summary of the feedback. The most useful problem statements provide context such as:

• What is the problem?
• What happens when the problem isn’t fixed?
• Are people doing anything about the problem currently?
• What do people dislike about the current solution for the problem?

Describing the Solution

Solution descriptions should have enough detail to convey how it will solve the problem and what are the primary components to the solution. Shape Up offers some great guidance on how to shape a solution. At its most basic, a solution description should include:

• The solution strategy - how will the solution solve the problem
  • Example: To let people get to town faster, while still allowing them to carry goods and people with them, we could use a carriage, but replace the horses with an engine.
• The solution components - what are the main pieces that make it work and some detail about how they might function
  • Example: A self-powered carriage would need:
  • A four wheel carriage
  • This would allow them to carry goods and people
  • We may need to have separate compartments for people and goods so people don’t get hurt by goods shifting during transport
  • An engine
    • This would provide the power in lieu of horses
    • It would have to support variable speed
  • Fuel compartment for the engine
    • This would be a place to store the fuel for the engine
    • It should be refillable
    • It would be nice to see how much fuel is available while operating the self-powered carriage
  • A mechanism for controlling the carriage’s direction
    • In order to navigate trails and streets, the operator will need controls to make the carriage go left or right
  • A mechanism for speeding up, slowing down, and stopping
    • The operator will need controls to vary the speed of the carriage as well as to stop it.
    • These controls should be located close enough to the direction control that a single person could operate the carriage.

Estimating the Value and Effort

At the dev idea level of detail, estimating the value and effort won’t be precise, nor accurate. The purpose of estimating is to establish a relative comparison between the dev ideas. At its simplest, teams could estimate the value and effort to be low or high. Or, teams with more wherewithal may prefer assigning points to reflect value and effort. Then, teams would be able to segment ideas into four quadrants:

• High Value and High Effort
• High Value and Low Effort
• Low Value and High Effort
• Low Value and Low Effort

Once ideas are segmented in this manner, it becomes easier to discuss the pros and cons of dev ideas within the same quadrant. For example, high value and high effort dev ideas are projects that could make a significant revenue impact. A discussion about which one to bet on could be productive. Whereas, comparing ideas across quadrants is challenging because the scale of value and effort is so different. Rather than discuss whether to do big things or small things, it’s more useful for teams to discuss which big/small things to do and how many small things can we do if we take on a big thing.

Teams may prefer to estimate value and effort together. It can be useful to hear multiple points of view to get a more accurate picture for a dev ideas potential value and effort.

When estimating, the product manager should also capture how confident the team feels about the estimate. Low, medium and high is generally a good enough confidence scale. When selecting low or medium, a best practice is to document anything that could increase your confidence. When deciding between two dev ideas in the future, the team may want to derisk a decision by increasing the confidence level in the estimates. At that time, it’s helpful to refer back to what would increase the confidence in an estimate in order to take action on it.

Idea Decision [Team Meeting]

Like Topic Decision, deciding what to do about the dev ideas is a team effort. Ideally, this includes the same set of stakeholders as the Topic Decision meeting. 

The product manager will select the list of dev ideas. Generally, the approach to dev idea selection should be:

• Newly completed Dev Ideas
  • These should be any dev ideas that have a problem statement, solution description, and value/effort estimates ready to review.
• Dev ideas with resolved questions
  • These should be dev ideas where all open questions have been resolved
• Parked Dev Ideas
  • Any parked dev ideas where the reason for parking them has changed

In the Idea Decision meeting, the product manager will take the team through the list of dev ideas one by one. For each dev idea, the team will decide one of the following outcomes:

• Shape
  • If a dev idea that is being reviewed, has any open questions, then they should be marked or kept at Shape. Since there could be many questions about how a solution may work, questions should be focused on:
  • Any uncertainties that could change the estimate value and effort
  • Clarifying whether a solution description would actually address the problem statement
  •  Clarifying whether a problem statement actually represents the underlying feedback
• Park
  • Deciding to park a dev idea means that the team doesn’t feel like the dev idea merits consideration for building. It could be for reasons such as:
  • The feedback doesn’t feel as urgent or important as it did previously
  • The solution doesn’t feel adequate, and the team wants to hold and come back to it later

For any dev idea that is parked, the product manager should capture the reason.

• Build
  • Deciding to build a dev idea means the team is ready to commit the resources to execution.

Closing the Loop

Handoff to Release/Project Management

For all dev ideas that are set to Build, the product manager will create a corresponding project, epic, or similar artifact in their release/project management system. With Upfocus, you can push your dev idea into Jira, GitHub, or Asana. You could also add a project link to another other system.

Updating From Build to Shipped

When closing the Flow, check in on the project status of all dev ideas set to Build. If any of those projects have been completed, then update that dev idea to Shipped. It’s a good practice to include a link to release notes in the originating dev idea.

Notifying Feedback Contributors

When a dev idea has been set to Build or Ship, consider notifying the people who have feedback attached to those dev ideas.