One of the most common questions I get from people in the process engineering space is: "What's the difference between what we do and product management?" And honestly, it's a fair question. When you look at the two lifecycles side by side, some of the steps feel familiar. But the intent behind each step — and where your involvement starts and ends — is very different.
I've worked both sides. So let me break it down. The industry standard BPM lifecycle — the one documented by platforms like SAP Signavio — has 5 phases: Discovery, Analysis, Design, Implementation, and Optimization. What I'm sharing below follows that same structure, but I've split Optimization into Measure and Optimise because in practice those feel like two distinct moments. And I'm layering in my own experience of what actually happens at each step.
Now let me walk you through each step
Before I get into it — a quick note. Process engineers don't just work in one mode. There's project-based work (where you're called in to fix or improve something), BAU work (making sure all processes are modelled correctly in the repository with proper BPMN notation and SOPs), and Lean Six Sigma projects where you follow DMAIC end to end. What I'm comparing below is the project-based PE lifecycle, because that's where the comparison with product management is most interesting.
Discover
This is where you sit with the business unit. You're listening — what do they actually do every day? Walk me through the process. Where does it start, where does it end, who's involved, what systems do they use? You're building a fact-based picture of the current state by hearing it directly from the people who live it. You might also pull system logs early on to get a data-driven view of how the process actually runs — that's process mining and task mining doing the heavy lifting before you even start drawing diagrams.
Discover
You're also talking to people — but the lens is different. Whether your users are external customers or internal teams using a platform you're building, you're trying to understand the problem space. User interviews, surveys, market research, data analysis. What are they struggling with? What do they wish existed? You're not just mapping what happens today — you're figuring out what's worth building.
Analyse
Now you map the as-is process — swim-lane diagrams, BPMN, process flows. But you're not just documenting what they told you. You're also identifying things they didn't mention. Pain points the BU raised, plus issues you picked up yourself. Maybe there's a bottleneck nobody noticed because they've been working around it for years. You're the fresh pair of eyes. Process mining goes deeper here — you use it to do root cause analysis, variant analysis (why does the same process run differently across teams?), and performance benchmarking against KPIs. You end up with a prioritised list of recommendations — each one backed by data and quantified impact.
Define
You take everything you learned in discovery and turn it into a plan. User stories, acceptance criteria, a prioritised backlog, a product roadmap. You're deciding what to build first and why. This is where you align stakeholders, set scope, and make trade-offs. A PRD or product brief usually comes out of this step.
Design
This is where you create the to-be process. You take the pain points — both the ones the BU raised and the ones you identified — and you design a better way. You model it in BPMN, run simulations and scenario tests to validate it, and clarify roles and responsibilities. Then you present it to the project team: here's the as-is, here are the problems, here's my proposed to-be, and if you implement this, here are the expected benefits. It's a full recommendation, backed by evidence.
Build
The engineering team builds the product. As a PM, you're not writing the code — but you're in every sprint. Clarifying requirements, unblocking developers, reviewing designs, making sure what's being built matches what was defined. You're the bridge between business and engineering. You're there from first commit to final QA.
Implement
Once the to-be process is approved, it needs to be operationalised — system configurations, workflow automation, new SOPs, pilot programs, training, UAT. The framework says this is still a PE step, and ideally you'd be involved in readiness testing and rollout monitoring. But here's the honest part: in my experience, this is where the PE's active involvement often drops off. You hand over your recommendation and the project team runs with it. That gap between the framework and reality? That's what pushed me toward product management.
Launch
You ship the product to real users — whether that's customers downloading your app or internal teams rolling onto a new platform. For external products, that means go-to-market strategy, release planning, and coordinating with marketing. For internal products, it's change management, training, and rollout comms. Either way, you're watching everything once it's live — feedback, adoption rates, issues. There's no hand-off. You're still right there.
Measure
After implementation, you come back to check if the benefits were actually realised. Did cycle times improve? Did error rates drop? Is the new process being followed? You compare actual performance against the benefits you promised in your to-be recommendation. Process mining comes back into play here — you use it to validate conformance, check if the new process is actually being followed the way it was designed, or if people have found workarounds. Real-time KPI dashboards help you keep a pulse on things without waiting for quarterly reviews.
Measure
You look at the data. Are users actually using the feature? Is retention improving? Are they completing the flows you designed? You track product metrics — adoption, activation, engagement, retention, and for commercial products, revenue. You talk to users again. You run A/B tests. The goal isn't just "is it working" — it's "is it solving the problem we set out to solve?"
Optimise
If the measurement reveals more issues — or if the benefits weren't fully realised — you go into continuous improvement. Tweak the process, address new pain points, refine. This is where Lean thinking and Kaizen come in. And if a bigger change is needed, you might kick off a full Lean Six Sigma project using DMAIC — Define, Measure, Analyse, Improve, Control — which is its own end-to-end methodology. Sometimes optimisation also means automation and hyperautomation — using RPA, low-code/no-code tools, or enabling citizen developers in the business to automate their own workflows. And when incremental change isn't enough, you go back to step one and re-engineer from scratch.
Iterate
Based on what you learned from measuring, you go back and improve the product. Maybe the onboarding flow needs work. Maybe users need a feature you didn't prioritise. Maybe the whole approach needs a pivot. In PM, iteration isn't a last resort — it's the default. You're always feeding new insights back into the next discovery cycle.
What about the day-to-day?
The lifecycle above covers project-based work — when you're called in to fix or improve something specific. But process engineers also do a lot of BAU work that doesn't get talked about enough. Making sure all as-is processes are properly modelled in the process repository using the right BPMN notation and standards. Ensuring SOPs are in place and up to date. And when improvements are implemented, updating the repository so the to-be process replaces the old one as the new as-is. It's not glamorous, but it's essential — because without that foundation, nobody knows what the current process actually is.
Product managers don't really have an equivalent to this. There's no "repository of all product states." The closest thing might be maintaining a product wiki or keeping your roadmap and backlog up to date — but it's not the same discipline.
So which one is better?
Neither. They're different tools for different jobs. Process engineering is about making internal operations run smoother. Product management is about building products that solve problems for users. Both are valuable. Both require systems thinking, stakeholder management, and an obsession with making things work better.
But if you're a process engineer who's been itching to be involved end-to-end — from understanding the problem through to shipping the solution and being there when real people use it — then product management might be the natural next step for you. It was for me.
And if you're already a product manager? Take some time to learn process engineering fundamentals. Understanding how operations work, how to map complex systems, and how to measure benefits — that will make you a better PM. Trust me on that one.
Agree? Disagree? I'd love to hear your take — especially if you've made a similar transition.
Let's connect on LinkedIn