Skip to main content

Author: Kevin Brennan

Value Stream Management

For the past couple of decades, companies have been trying to do process improvement in knowledge work through projects.

After all, a better process needed a better IT system designed to support it, and the primary way we delivered new IT systems has been through projects, right? But in practice it often didn’t work as well. A project-based approach to process improvement led us to business process reengineering, to expensive and failed redesigns of processes at a large scale, and away from methods such as Lean, Six Sigma, and Theory of Constraints, which had shown their effectiveness in manufacturing contexts.

It also led to a deep separation between business process management approaches and the technology used to implement and support those processes, to such an extent that professionals in business process management and business analysis had distinct job roles and functions, even though business analysts were spending most of their time automating processes! Nevertheless, the realities of implementation forced us in this direction.

In recent years, though, the basics of delivering technology in the enterprise has changed, but business process management and business analysis haven’t caught up to this new reality. In practical terms, we no longer need to develop custom applications to automate most of what a business does—purchases of off-the-shelf or SaaS applications do most of what we need, with the appropriate implementation.

Finally, when we do need to build custom applications to support the business, we no longer need to deliver them at the end of a multi-year project. Agile methods allow for software to be improved continuously and delivered to the business at the same pace that we can change business processes.

There’s no reason business process improvement should be done as large reengineering projects any more. The governance and technology supports are there for a genuine commitment to continuous improvement in knowledge work. In short, it’s time to combine business process management and agile to drive a new wave of process-centric improvement to business. This is what value stream management looks like: using lean, theory of constraints, and other methods designed to deliver process improvement in combination with story maps and other agile tools to improve the process and the technology together.


This isn’t a big stretch—agile thinking already borrows heavily from continuous process improvement, particularly Lean and TOC (in fact, it takes more from the process improvement concepts of those approaches than it does from the product development experience, but that’s another discussion for another time). We know, from experience, that continuous process improvement works. We also know that agile software development works. What we need is to integrate the two together to address the limitations of each.

Although you’ll find the term used widely in agile literature and in business architecture, the term “value stream” originates with lean process improvement. In lean, a value stream consists of all of the activities required to deliver a product or service to a customer (specifically, an external customer). It can include one or more business processes. The point of identifying something as a value stream is that we can assess all of the individual steps in the stream to determine whether they actually create value as judged by the customer. Any activity that doesn’t create customer value is considered to be waste, and should ideally be eliminated.

That “ideally” is an important caveat. In practice, there’s work that can’t easily be eliminated, even if it doesn’t provide significant value from a customer perspective. Much of it may be needed for other reasons, including regulatory compliance, or practice constraints. However, much of it really is unnecessary work, or what Lean terms “waste”. A review of a typical process will show that about 80% of activities are typically non-value added, and those are the steps you should work towards eliminating. While Lean methods aren’t specifically focused around business agility, removing waste will lower costs and make it easier to introduce improvements and deploy new products.

That’s the key business benefit of properly managing your value streams. A lean, well-managed value stream lowers costs to deliver products and services and is easier to change in response to shifting market conditions. In practice, one of the most significant constraints on improving your value streams is the technology companies use to support them. Old legacy systems tend to have substantial waste baked in. Even processes that might originally have been lean are now burdened with all sorts of workarounds to accommodate contingencies that weren’t anticipated when the systems were designed, and they become increasingly difficult to update.

To manage the modern value stream, we have to stop treating business technology as something that follows the process and work on deploying and modifying it as part of the process. That means the value stream manager must combine process thinking with technology expertise. We need to design value streams using and deploying commercial applications whenever possible, matching them to the process objectives such that it’s comparatively easy to modify through configuration options. We need to be able to guide operational workers and managers and help them understand when custom development is a viable option (in other words, learn when that development effort really does meaningfully affect customer value).

Value stream managers will also need to work closely with external and internal product teams. They support external teams by ensuring that the back-end processes deliver on the needed customer experience and that their value streams can respond quickly to new product demands. With internal teams, they need to help those teams understand the capabilities required by the value streams and help them build systems that are flexible and adaptable enough to support rapid change.

Value stream management represents a significant competitive advantage for companies that can implement it, but it’s going to require that we get past the existing process/technology divide and prepare for a future where they work in unison.

Should Business Analysts Become Product Managers?

Product management has been around for decades.

However, the recent rapid adoption and reframing of internal applications as “products” to support agile transformation, means that the demand for experienced product managers is much greater than the supply. I made the shift from business analysis to product management about a decade ago (specifically, managing products aimed at business analysts), and I’ve found it to be a challenging and rewarding role. It can also be a stressful one. Many business analysts have the skills and attitude needed to succeed in a product management job, but it demands that we learn new skills and develop a different mindset.

Many BAs come into projects after the business case is written and the general form of the solution has been chosen. BAs make recommendations as the project progresses, but those things are ultimately owned by the project sponsor. That’s not true for product managers. PMs are ultimately accountable for the success or failure of their products, and will have to justify every investment of time and effort against the competing resource needs of other products.

Even if you take over a product that’s already in the market, you’re going to be held accountable for its future success. Think about every feature and consider whether it’s worth it from a business perspective. Consider whether existing features do the job, or whether they should be modified or even removed.

Get into the room with the sponsor and make the case for the capabilities you believe will best help them achieve their goals. You need to be ready to own those decisions yourself. You need to articulate the business need, connect a proposed solution directly to it, and persuade other stakeholders that your solution is the right one. And yes, I wrote your solution. You own it, even though you’ll likely have to convince gatekeepers that you’re taking it in the right direction.

BAs are used to solving problems inside a company. Those problems are often very complicated, requiring you to bring together diverse stakeholders to find a solution, but at least all the stakeholders are inside the company and you can talk to them (well, at least in principle). A product manager doesn’t get to do that. As a PM, your customers are external. You can and should talk to as many of them as possible, and if your company has a good market research team, you may have a decent idea of what they want, but you’ll always be working with less information than you’d get as a BA and you must get used to implementing ideas that represent your best guess about what they need.


On top of that, you’ll always be dealing with competitors. If you have a great idea, they might develop a copycat product that leverages your work and puts their own spin on it. You must make sure that your product offers something unique that appeals to your customers, figure out what needs they have that your company can meet more effectively than its competition, and use that as the basis for an overall product strategy. Be ready to adjust your course as much as you need to and prepare for constant change.

Think of your product as a business of its own. Product Managers are often described as “mini-CEOs”, and while I think the comparison’s often overblown, this is the grain to truth in it. You must understand your product’s value proposition, what makes it unique, and constantly look for ways to enhance the value it’s delivering for both your company and for your customers.

If you’ve decided that this is something you’d like to do, you must find opportunities to get into PM work. Here are a few concrete steps you can take while working as a BA to make that transition.

  1. Find chances to work with UX professionals and your company’s sales and marketing teams. They’ll be some of your key partners as a PM, so understand what they do and why. If you need to, get some training in these areas. You don’t have to be an expert in these areas, but you need to know enough to know when it’s being done well.
  2. Work on customer-facing projects. You need to connect your job to work that drives revenue for your company and learn how to find those opportunities to change a product to drive growth or improve retention.
  3. Engage with business cases and project sponsors. Do you understand how the project you’re working on will increase revenue, avoid costs, or improve service, and what the specific targets are for it? Can you explain how your requirements support those goals? A PM shouldn’t be putting anything into a product without being able to explain why it’s there and how it will help.

If product management is something you’re interested in, business analysis is a great place to start from. You already have extensive experience working with stakeholders across your enterprise to develop a shared vision for a solution, translating their needs into requirements, and working with developers to implement them in software. You’ve also developed an in-depth understanding of the industry sector you work in. These are all excellent qualities in a potential product manager.

The greatest difference between business analysis and product management is that you’ll have to take responsibility for aligning everything you do to the value proposition of your product. You’ll be expected to drive the needed business outcomes whether or not you have the authority and resources you want. Even so, your product may succeed or fail in the market for reasons beyond your control. But you get to execute on your vision rather than someone else’s. If that idea appeals to you, then product management is the natural next step in your career.