Flow: Lean Product Development Principles for Optimizing Workflows

Ask a PM about their day-to-day, and they’ll likely tell you about their company’s mission (“Our software will change the world”), their customers (“We have a really robust, engaged community”), the initiatives they are working on to help their customers and in turn their company, and HOW they are getting that work done.

When the topic of HOW is brought up, you can see fellow product managers start to straighten up a little bit, and perk their ears towards the conversation at hand. Most product managers have strong opinions about optimal workflows, whether their preference be Scrum, Kanban, or other Agile project management systems. And with good reason! If members on any product development team haven’t figured out how their team works best, all of those other things are that much harder to fall into place.

For me, I’m in the camp that there is no one size fits all workflow style for everybody, and that it’s imperative that you should choose the right workflow for the team and the environment. As I recently started a new position at a new company, our team made the switch from traditional Scrum to a Continuous Flow product development cycle.

Here’s why we made the change:

We were spending too much time in meetings planning for work. Hours upon hours were being spent every week to discuss and plan for features. I am all for spending the time up front to hash out the best strategy to approach a feature, but we were planning for work during a two-week sprint cycle that many times never got done.

Which leads me to my next point. There was too much work being worked on at any given time. We were shoving features in to our sprints for the sake of filling capacity, while knowing that work often wasn’t going to be completed within that two week sprint window.

Often, the scope of a feature was unclear: Being tied to a rigid sprint planning schedule, and being driven by the fact that everyone needed to be “filled up” to capacity was forcing Product to rush certain features, which often left a lot of holes and ambiguity into what the team was building.

Our new workflow is based on lean manufacturing principles from the book Principles of Product Development Flow by Donald Reinersten and covers 7 key principles that can be boiled down into three centralized themes:

1. Prioritize based on economics using the cost of delay framework, and manage your backlog accordingly. Our team has found this to be extremely beneficial not only to prioritize work, but to be able to communicate to the business what value we project to bring by delivering any feature. For anyone looking at different frameworks for prioritization, I encourage you to check out this one.

Source: BlackSwanFarming

2. Limit work in progress at any given time. Ensure that the team is working on the highest priority features, break that feature down into the smallest unit possible, and avoid the cost of delay. Meaning, if you can get something done faster by having two people working on it, instead of one, do that.

3. Get feedback early and often. Rather than waiting for a two-week sprint to be over to unveil your work (ta-da!), we employ desk checks as often as needed to look at work and provide feedback. We’ve applied this principle to both engineering and design teams, and have found both the quality and speed in which we deliver to have improved.

The change has been successful in that it met all of the key results we were tracking, including:

1. Reduced Time to Delivery: Moving away from formal sprints is hard for some product managers (it was initially hard for me!) in that you’re giving up a bit of control and handing over the power to your engineering teams to work on features at their own pace. In my opinion, decentralizing control is a good thing and the move enabled us to be more nimble and deliver value more quickly.

2. Ability to Articulate Value: By using the Cost of Delay framework, as a product team, we can concretely say whether or not a feature was actually successful, and if it delivered the value that we expected it to. This has been extremely beneficial in allowing us to quantify what was a “Win”, and where we came up short.

3. Team Morale: Who doesn’t love less meetings? In addition to spending less time zealously planning, the team has more ownership over their workload.

And while I encourage any working PM to checkout Flow and the principles outlined, my intent is not for you to become a convert, but to advocate for you to approach any new team with eyes wide open, and to continue to optimize the way your team works like you would with any product or feature.

If you have questions about how your team can find Flow, drop them into the comments below! You can also connect with me on LinkedIn here.