Disclaimer: This is based off of my own view on this concept and I’m just looking to shed some light on what I have learned and experienced so far.

Success is not measured by how many features that have been built or issues that have been resolved, but instead by how those features or solutions have resulted in success for the Product.

While this seems like an obvious statement to make, some Product teams still get lost on “what” they are building without considering “why” they are building it.

If you’ve researched or studied anything related to Product Development, you know that the “why” behind important decisions is crucial for the overall success of the Product.

There are still instances where this mindset isn’t completely embraced by Product teams or their Executives. Some of these Product teams are getting away with providing no value at all and being praised for it.

Output-Focused Teams

Output-focused teams are constantly focused on just what they are being told to build — whether that be new features, bug fixes, or design changes. What I’ve seen from these teams is a focus on “what” without any focus on the “why”. These teams tend to have roadmaps that present different features or projects in a row. Some of these features or projects might be valuable, but most won’t move the needle at all.

For example, a traditional, output-focused team’s goals might look something like this:

• Build a Login Page
• Create an Ordering Experience
• Create Landing Page

These teams generally have no sense of what their objective is and will hardly mention the impact of a specific feature or project. These output-focused teams will accept any feature request and build it. They are instantly glorified for their hard work once the request has been built and released. They have adapted to building any feature that users or Executives request; they are nothing more than a build factory. The delivery of these features is what makes these teams look and feel successful even if the company is drifting away from initial intentions. These teams are doing the exact opposite of what they should be doing.

Most importantly, this type of team is taking the easy path and isn’t being challenged. They’re able to sweep results of features under the rug because Executives are happy as soon as it’s available to users. These teams don’t think enough about what success truly looks like and aren’t looking out for the best interest of the Product.

Executives should worry heavily about output-focused teams. Although Executives may think they are getting what they want, these teams are wasting money and resources on goals or projects that, in most cases, won’t have any positive effect on the end user. There’s a good chance it’s an output-focused team if they aren’t pushing back on feature requests.

Any team that’s easily influenced to take all requests without a clearly defined “why” — will almost always be going in the wrong direction.

Outcome-Focused Teams

Alternatively, outcome-focused teams determine what goals to focus on in order for them to hit their objective(s). They aren’t as focused on quantity and are instead focused on providing the right solution to users. They spend time figuring out customer pain points that need to be solved and solve those problems with the intent to improve the user experience, influence user behavior, and support their company’s objectives. They pick the right problems to solve based on what they’ve validated will result in the biggest impact on their objectives. Executives will, undoubtedly, see the value of these solutions as these key metrics or performance indicators move in the right direction after release.

Outcome-focused teams know the direction they need to head in order to achieve the Product Vision. They develop roadmaps with goals that are delicately selected with the intent to help them achieve their daily, weekly, monthly, or quarterly goals once they are sure of these objective(s).

For example, a traditional, outcome-focused team’s goals will look something like this:

Reduce the time it takes for users to sign in by 10%

• Build a Login Page

Increase conversion of orders from 55% to 65%

• Create an Ordering Experience

Increase brand awareness by 35%

• Create Landing Page

The ideas that exist as a part of these projects or features would collectively drive the objective(s).

An iterative, outcome-focused team’s goals will look something like this:

Reduce the time it takes for users to sign in by 10%

• Allow users to sign in with email and password — Login Page MVP
• Allow users to sign in with their Google account — Login Page v1
• Allow users to sign in with their Facebook account — Login Page v1.1
• Provide users a way to sign in with facial recognition — Login Page v1.2

Increase conversion of orders from 55% to 65%

• Allow users to select products and checkout — Ordering Experience MVP
• Provide users a way to search for products — Ordering Experience v1
• Allow users to set filters for products — Ordering Experience v1.1

Increase brand awareness by 35%

• Provide users a basic summary of the product — Landing Page MVP
• Attach logos and images throughout the landing page — Landing Page v1
• Display product reviews — Landing Page v1.1

If a team adds filters to the ordering experience and the conversion rate began to decline, the team will consider that a failed goal. They will reflect on that failure and adjust.

This outcome-focused thinking will work regardless if your team is more familiar with traditional development or continuous delivery. Since the team is able to identify what their objectives are, they are able to determine different goals for how they can get there. They are solely focused on how they can achieve these results.

These teams have the ability to reflect on the solutions or goals they have provided to see if they are getting closer to the Product Vision. They own up to success or failure on the decisions that were made along their journey to the Product Vision.

These outcome-focused teams are obsessed with driving results for the company and know how to say “no” because the ideas don’t align with these objectives. The team’s effectiveness is truly measurable and quantitative. Executives should be confident if they have teams that push back on their requests frequently. These teams are doing everything in their power to stay in the lane that will drive the Product towards its vision.

My Experience

Overall, being a part of a team that is outcome focused has resulted in an incredible passion for the Product. Every member of the team is obsessed with how we can achieve our objective(s) for the Product, and we aren’t afraid to make decisions. This is only possible because we know what value looks like. We are able to share success with the organization by solving the right problems for customers.

If you haven’t made this transition, I encourage any team to solely focus on their “why” above all else. All teams should work with Executives to find out what they want to see from the Product and clarify the vision. Product Managers or Product Owners should stop spending most of their time around the tactical work and start thinking of their path towards achieving the Product Vision. If it’s not being given directly, I recommend teams to identify every user problem, request, or idea that persists. Eventually, these requests will have a common theme. This common theme is an objective.

Most importantly, these teams need to use the objective to fuel their decision making. Then, use both qualitative and quantitative data to determine what initiatives to focus on to achieve that objective. These objectives will provide teams the opportunity to develop a successful Product in a way that no one could have anticipated.

‍