Why BPMN Modeling Pays Off on Your Project

Taking an idea from concept to market is an exciting time. Maybe you’re just starting, or maybe you’re in the thick of building or enhancing a product. We all experience similar pain points in the product development process. The team is trying to understand the concept and scope of work: developers are trying to get a grasp of what to build; product managers are trying to figure out how to eloquently solve problems; and many times product owners only have the big, overall idea in mind with no approach to get there. Taking a problem or pain point and finding a solution that can be built out quickly, then iterated on, is the main puzzle for the team to solve. As a Product Manager, one must be diligent in laying out those problem statements and ideas in an effort to get everyone to buy-in on the overall direction.

At Revelry, we have found that using BPMN diagrams (Business Process Model and Notation) can ease some of this pain and help everyone truly grasp the direction of a product.

BPMN explanation

Gaining momentum and achieving buy-in is extremely important through all phases of product development. If the entire team is on the same page with the vision and the priorities, it’s amazing how much can be achieved in a relatively short amount of time. This is where a Business Process Model can come in handy. BPMN gives all stakeholders a graphical representation for specifying processes inside of a business model. In my case, this could be a user or system flow. You can read more on the specifics at bpmn.org or good ole wikipedia.

Building out a business process model helps everyone get on the same page, notice gaps in logic, and see the complete picture of what they’re building towards.

How is this different than a Product Roadmap?

Roadmaps generally consist of a list of features in priority order. The BPMN diagram(s) show the actual flow and how these features will interact with one another. This works better because it’s much easier to fully grasp the complexities of flow when the features are chained together visually as units instead of being represented by disconnected entries in a spreadsheet or Gantt chart. A Product Roadmap is a list of features. A Business Process Model is a visual workflow that shows how each of these features connects and how they are utilized by different roles or user types.

How is this different than a Whiteboarding session?

Whiteboarding sessions are awesome — you may even be drawing some sort of models on the board! The nature of a remote work culture like we have at Revelry can be asynchronous. Whiteboarding is most effective when everyone is gathered in-person in a single room. It’s torturous to try to Zoom in remote teammates for physical whiteboard sessions.

Also, have you ever tried looking at the whiteboard from a session you weren’t involved in? It’s essentially someone else’s notes. More than likely, you will derive different meanings from what is scribbled on the board than what was intended by the person or team that put it there.

A Business Process Model uses a standard language. Whether you were in the room or not when the model was made, it is much easier to grasp the author’s vision and assumptions about the product and where it is heading. I’m certainly not saying stop whiteboarding. What I AM saying is also use BPMN to summarize make shareable the results of your whiteboarding so others that may be jumping in late can quickly see your vision. Also, your BPMN diagrams will be editable via version control, something you can’t really say about whiteboard PNGs. 😉

Pros for Product Owners

In my experience, product owners love BPMN diagrams. First and foremost it lets them know that you understand their complete vision. It’s refreshing when you sit down with your product owner and find that you are in sync with the goals for the product and everyone is comfortable moving forward.

More importantly, is when you’re NOT in sync. When you rely solely on meetings and verbal conversations to try to communicate ideas, signals can get crossed. People leave those conversations feeling they understand one another. In reality, they often don’t.

It becomes apparent very quickly when a stakeholder looks at a model that is not in line with their visions and goals. This should cause a conversation where everyone becomes aligned and a new model is produced based on the conversation. BPMN is a great way to have everyone’s vision aligned and force the conversation when they are not.

Pros for Product Managers

The act of modeling for a product manager also proves to be very fruitful. It forces you to really understand the scope and complexities of the product. It’s easy to find gaps in logic and forces critical thinking when you’re interacting with the user flows and how they each affect one another.

Modeling also serves as a way to highlight complexity. It can be a very useful tool in determining where features should be streamlined, or when units of work need to be split apart.

As mentioned above, it really pays off in conversations with your product owner as they see the output of how you interpret their vision. Right or wrong, it causes great conversations and forces the whole team to be on the same page.

It can act as a great progress tracker for your application and can even act as an epic for features if you decide to get a little more granular and model each feature out.

Finally, modeling can greatly help the user story writing process as you have a visual to track the headlines and stories you’ve written.

Pros for Developers and Designers

BPMN can be a great tool for Designers and Developers as well. It’s much easier to comprehend the overall goal of a product with a visual diagram. It’s useful for identifying the more complex features as it shows relationships between user types and systems.

Modeling allows you to call out missing logic and more easily identify potential pain points as well. I like to include images of feature models in the background of our user stories so the overall picture is easier to grasp during planning poker. It provokes bigger conversations and better estimates on issues.

Pros for QA

Quality Assurance teams also benefit from BPMN models, especially feature models. When your QA teams are working multiple projects to identify bugs and pass features it’s not always obvious off the bat how a feature is intended to work. When a model is available, the workflow objective becomes evident and improves the speed and quality at which it is tested.

How to implement into your process

I’m still fairly new to BPMN. I haven’t yet learned all the terms or the 100% correct way to use all of the objects. Honestly, it doesn’t really matter. I already see great benefits across my teams when I introduce the models and get everyone’s buy-in. It increases team alignment and helps everyone make decisions related to each of their roles. How you introduce BPMN is up to you. Just like anything, find your sweet spot and what works for your teams. Since I’ve already noted the benefits above, now I’ll share how we at Revelry implement BPMN.

We start the project with a simplified version of the Core Loop of the intended product. This allows us to get buy-in from the product owners and the team on what features are core to the process and we prioritize from there.

Once we have determined the feature set and priority of those features, a feature model is crafted if it involves enough complexity. We again get buy-in from the entire team. Then the feature model is used to write out headlines, followed by user stories, making sure to include the models in the background section of the issues.

The XML files and static images of the models are committed into git history so they are accessible anytime in the repo and anyone jumping on the project may update them if a user flow changes. As the product grows and more and more features are prioritized, we continuously update the original core loop model.

I’m excited to learn more about BPMN and find ways to actually automate processes using it. But even the simplistic way in which I currently incorporate them really seems to pay off. I encourage all teams to give BPMN models a chance.

---

Product Management Project Management