As mentioned in the previous flow post, flow is the secret sauce for delivering maximum value to users in the shortest possible time.  

By optimizing flow, you’ll be able to take control of your workflow and more quickly (and continuously) adapt your product strategy and development processes, which is critical for any organization wanting to become more product-led. The right solutions will be identified and delivered faster because feedback loops will become shorter. 

At the end of this article, I will share 9 ways to optimize flow to become more product-led that came out of a great conversation with fellow Dandy Johan Wildros, an expert in using Lean Agile principles to optimize flow. We worked together at If insurance on an Agile transformation of one of their core systems. You’ll also find helpful tips for getting started and things to watch out for. Feel free to jump to the tips at the end if you’re eager to see the 9 ways.

Product-Led Organizations

In a Product-Led organization, delivering products that solve real customer problems is the top priority. Such organizations recognize that business, product, and technology must work in harmony in order to build products customers love AND are equally valuable for the business. They optimize for their business outcomes, align their product strategy to these goals, and prioritize working on that will help develop those products into sustainable drivers of growth. 

Making that happen requires that a number of critical organizational and team-level capabilities are in place, all of which rely on optimized flow:

• Information and strategy are quickly coordinated and communicated across the organization to ensure alignment and understanding. 
• Product development and management are synchronized so that strategy informs the activities of the product development teams, and the value-driven operational measures inform the company direction. 
• Strategy is operationalized by setting the right levels of goals and objectives throughout the organization so that teams have a robust decision-making framework that narrows down their playing field.
• Strategy is yearly or quarterly (not multi-year) so teams can make outcome-based decisions on a monthly or weekly basis.
• People have the necessary time to do product vision and research to uncover customer needs.
• Product discovery and delivery are done within Agile product teams with as few handoffs as possible and as much direct customer contact as possible.
• Expected outcomes and goals are passed down instead of feature requests so that team activities can be directly linked to company outcomes.

Why Becoming Product-Led Starts with Flow

Becoming a product-led organization starts with optimizing flow to ensure the system isn’t flooded with too many parallel activities so there’s enough slack in the system for continuous improvement, experimentation, and adapting to the unknown. 

Organizations that are product-led treat software as a strategic advantage, which relies on alignment between the IT function and the rest of the organization, along with the ability of IT to execute. The data cited from a report for the MIT Sloan Management Review, “Avoiding the Alignment Trap in Information Technology,” found that companies whose engineering teams do a good job of delivering their work on schedule and simplifying their systems achieve better business results with much lower cost bases, even if their IT investments aren’t aligned with business priorities. Focusing first on flow is aligned with these research outcomes because it creates the organizational context needed for balancing the work you’re doing to improve your capabilities against the delivery work that provides the value to customers.* 

9 Ways to Optimize Flow

As mentioned above, optimizing flow requires working in ways that don’t flood the system with too many parallel activities so there’s enough slack in the system for the unknown. Below are 9 actionable “starter steps” that anyone can start implementing right now to optimize flow and create the foundation for becoming product-led, which are organized into the following themes: Address the System, Address the Work, and Address the Team.

Address the System

#1: Make Sure You’re Working on the Right Things

Identify the customer problem that your solution is meant to solve. Understand how the solution you’re building and delivering solves the problem. Work towards defining, measuring, and managing outcomes (customer-value metrics) rather than outputs (activity-based metrics). 

Tips for getting started:

• Embed feedback loops within your organizational system for ensuring that you’re working on “the right thing” such as prioritization models, cadenced stakeholder conversations, an outcome-based OKR system that makes clear the connection between business goals and operational activities, etc.
• Regularly refine backlogs to ensure they’re aligned with your organization’s OKRs (i.e., goals, strategies, and priorities for solving customer problems) and get rid of items that naturally “age out”.
• Work in smaller batches (see #5: Work in Smaller Batches)

Things to watch out for:

• Not considering all needed perspectives

#2: Create a Pull-Based System

A pull system means starting new work only when there’s internal or external customer demand for it. It allows for managing throughput rather than capacity or utilization. It also decreases lead time and increases predictability, all of which optimize flow.

Tips for getting started:

• Visualizing your process and the work flowing through your process using Value Stream Mapping (see #3: Do Value Stream Mapping).
• Identify and minimize waste using Value Stream Mapping.
• Limit work in process using a Kanban board.

Things to watch out for:

• Too much variation in the size of work items which will impact predictability
• There’s always going to be some “very important” project that business insists must get started “right now” which will throw a wrench in the pull-based system. However, as long as you have set up visualization of your work and pull to your own capacity, you should be good.

#3: Do Value Stream Mapping

A value stream represents the flow of work from a customer request to value delivery. Mapping out the flow of work by visualizing the processes and adding key pieces of data describing the state of work along the stream helps to identify and remove or avoid non value-add activities. The result is optimized flow. 

Tips for getting started:

• Select the product or service you want to map
• Create a reference group of no more than 10 people involved throughout the value stream, which could include the product’s business unit, product marketing, design, finance, development, QA, and operations. 
• Focus on one specific, known (well-defined) product and one specific well-known and agreed upon case (i.e., bugs or development).
• Start from the end of the value stream and work your way to the beginning.This is helpful because the value stream always becomes transparent when you do releases and customers start using the product, whereas it’s not always clear when starting with “customer request”. We’ve found that starting at the end keeps energy and momentum high.
• For each process block within the value stream, record the following: The activity performed in that block, the name of the team or function that performs the activity, the number of people involved, any significant barriers to flow, queues between blocks, as well as lead time, process time, and percent complete and accurate.
• Once the current state map is created,  a future-state value stream represents how you want the value stream to flow at some future point—typically in one to three years (to avoid the common mistake of trying to improve through local optimization).

Things to watch out for:

• Loss of energy and momentum if starting out at beginning of the value stream map (as opposed to the end, which is where we recommend starting)
• If you get stuck, move on instead of worrying about being 100% correct. You can do the value stream mapping in layers, starting with activities, then owner, then how long it takes to do the activity, and so on, instead of trying to be accurate during the first go.

Address the Work

#4: Unbundle Features From Projects

Unbundling projects into requirements that can be prioritized independently will increase throughput, which is a measure of flow. Unbundling projects will also ensure that lower-value features are not batched together with higher-value ones, so that teams are only working on the most important work items, and that each increment of the solution can be validated as it’s produced, as opposed to validating only at the end, when the whole solution is completed.

Tips for getting started:

• Find a small project that will turn into a product, and determine beforehand who will own and take care of it throughout its lifecycle, and make that person the Product Owner, and then treat the project like any other product. This means the work items can be the same size as those of the projects but the slices will be different because it will contain full functionality and will deliver value right away. Although it may not always be possible to do this, you can always strive to have something to deliver (i.e., delivering UX without backend)
• See if you can deliver anything that is usable in small batches so you don’t have to validate everything at once. Projects still need to be broken down into features and user stories to decrease complexity before any work is started. However, not being able to validate the solution until the end means customer validation won’t happen until the end.
• Introduce customer-facing interfaces to get early validation from customers  (see #9: Bring Teams Into Contact With Customers).

Things to watch out for:

• Make sure of who is owning the product as you’ll end up in situations where you won’t agree on solutions and there needs to be someone who can make the ultimate judgment call.

#5: Work in Small Batches

Working in small batches allows for the rapid testing hypotheses because it reduces the time required for getting feedback on changes and/or improvements. The results are increased innovation, shorter lead times, higher quality, and lower costs. 

Tips for getting started:

• Slice for value using user-story mapping
• Make sure you know what you are doing before you do it (i.e., don’t just start building and hope for the best)
• Unbundle projects into requirements that can be prioritized independently (see #4: Unbundle Features From Projects).
• Reduce the size of requirements
• Break work items down into a size that is deliverable in a few days or, at maximum, one week (i.e., a size that is deliverable)
• Limit work in process.

Things to watch out for:

• Just realizing that finding the sweet spot for making batches and work items “not too small” takes practice (so treat it like any other project with a hypothesis and experiments and evaluate the size that you find the most effective for you).

#6: Minimize Tech Debt

Minimizing tech debt keeps developers as free as possible to innovate, develop, and take care of their product throughout its lifecycle.

Tips for getting started:

• Adding more user-journey tests
• Employ good architectural practices such as modularization
• Adding more basic unit tests
• Make sure all new code written on the feature uses test-driven development (NOTE: Many people are not doing TDD but it does help)

Things to watch out for:

• Minimizing tech debt should be an expectation that Management has on teams, not vice versa. 

Address the Team

#7: Make Teams as Cross-Functional as Possible

Ensure that teams have the people and resources they need to design, run, and evolve experiments. Cross-functional teams have end-to-end ownership over a product, so they have day-to-day contact with the operations of their software, which is a critical feedback loop for ensuring quality. 

Tips for getting started:

• You can start strengthening cross-functional collaboration right now, even if your organization is not ready to create cross-functional teams, by identifying and incorporating your upstream and downstream contributors into a single voice with a set of working agreements around specific alignment, coordination, and decision points. You may not be a formal cross-functional team on paper but you’ll be functioning like one.

Things to watch out for:

• Stay sensitive to your organization’s political landscape when increasing your virtual team size. Everyone usually wants to be helpful but may have different expectations coming from their managers which could lead to working at cross-purposes (so stay aware of this).

#8: Make Teams as Autonomous as Possible

Having cross-functional teams is not enough. The software architecture and the organizational structure have to be such that teams can be autonomous so that teams can experiment without impacting other teams and deliver autonomously.

Tips for getting started:

• Define interface between teams so they can be autonomous within the boundaries of APIs and, if they’re sharing an area, not changing the contract but the content.
• Move towards service oriented architecture and align API boundaries with team boundaries so that teams can be as autonomous as possible, which is critical for running experiments and responding quickly to customer needs and get changes out as quickly and safely as possible. 

Things to watch out for:

• Watch out for politics and setting the right expectations
• Remember that creating autonomous teams won’t change your organization overnight. Many other factors have to be aligned and put into place, such as an optimized value stream, a mechanism to strategic alignment such as OKRs, rewards and bonus structures that reward behaviors needed for delivering the right-things-at-the-right-time, etc.

#9: Bring Teams into Contact with Customers

Teams need to be in contact with customers to get quick feedback regarding if the features they are releasing are adding value to the overall customer experience.

Tips for getting started:

• Ask Product Owner or customer reps (i.e., those on the sales side OR someone representing the voice of the customer when it comes to product questions) to invite real customers to attend demos and/or planning sessions.
• Create a dedicated feedback page, run surveys on your pricing page 
• Use a Facebook group to ask their audience what they think of your product.

Things to watch out for:

• Don’t forget to include consideration of internal customer feedback. We once worked with a team who had users raving about their responsiveness but very unhappy internal stakeholders who didn’t know how to get their needs prioritized. After some digging, we learned that the team had a direct customer portal where real-time feedback could be obtained but no feedback loop with internal stakeholders. The situation was remedied using OKRs and working agreements around how to quickly get business critical (often ad hoc) needs to the teams.

Hopefully, these 9 Ways to Optimize Flow have inspired you to find additional ways to shore up your foundation for becoming more product-led. If you have any stories to share, comments, or ideas for additional steps, let us know in the comments below!

*For more information regarding the aforementioned study and analysis, check out the book Lean Enterprise, written by Barry O’Reilly et al