What product managers need to know about business rules


Accelerating Products

I mentioned in the last issue of InsideProduct that I am one of the track chairs for the Accelerating Products track at Agile2024. It’s my attempt to build a stronger appreciation between product people and agilists.

The submission period is now open, so if you’d like to speak at Agile2024, submit your session today.

I look forward to seeing your submissions!

What you need to know about business rules

If you’re a longtime reader of InsideProduct, you’re familiar with the idea that business analysts are product people and can move into product management roles.

One reason I believe that is because business analysis is an important subset of product management for dealing with requirements and business rules.

Business rules play a big part in any software product, because they govern the logic that a product applies. In a B2C product business rules come into play when describing how to determine the price of a product, especially one that has options and is configurable.

In a B2B product business rules play an even bigger part, providing guidance on how to route work, and describing the decisions that occur in a business process.

Yet when I looked for resources to share about business rules, I struggled to find any that dealt with business rules from a product management perspective. So the resources I’ve shared below come from the business analysis community or related articles I’ve put together.

That dearth of content has encouraged me to add a technique brief on business rules to my to do list. Let me know if there are particular questions you have about business rules.

Hopefully, these articles provide a bit of insight into what business rules are and how they can be useful for your team.


Product Management Training

The end of the year is a great time to look ahead and make plans for how you’re going to make the next year great. One way to do that is to learn some new, or strengthen some existing, product management skills through training.

Gigantic is a great place to go to find training to help you with new or existing product management skills.

They offer live, small-group cohort based training in a variety of product related topics including:

  • Product Management
  • Becoming an AI Product Manager
  • Mastering Customer Research
  • Product Strategy for Product Managers
  • Product Leadership

With any of their courses, you get to attend weekly live sessions with an intimate group of your peers who are taking the same course, at the same time.

Gigantic supports a global community of students, so you’ll be matched to a cohort that works with your time zone!

I’m happy to announce that I’m an affiliate partner* of Gigantic and can offer a 10% discount for any course you sign up for using the discount code KENT10.

Now’s the time to line up your training plans for next year. Go to Gigantic, pick your course, and use the discount code KENT10 for 10% off.

*Since I’m an affiliate partner, for every purchase you make after following the link above, I’ll get a small affiliate payment, at no cost to you. Truly a win-win!


Identifying and documenting business rules

Karl Wiegers explains that policies, regulations, standards, and other business rules are important sources of software requirements.

Business rules — or business logic — are statements that define or restrict certain aspects of an organization’s operations or influence the behaviors of people and software systems within the organization. Rules often exist and apply beyond any particular software application.

What are business rules? (And how to implement them)

Every day, every employee in every department makes decisions. Without guidelines, these individual decisions are haphazard and sometimes at odds with each other. But it’s possible to ensure that you align each action with the overall goals of your organization.

All you need are business rules. And you need to implement them in a way that makes your business operations more efficient, not less. The Monday.com team introduces business rules, what they are, and how to do them right.

Escaping the “business rule” trap

Over the years, Vishnu Nair has worked with many organizations and has observed how accumulated business rules pose significant challenges to scalability, transformation and organizational agility. Business rules are operational rules that organizations follow to perform various activities. Over time, as organizations grow and adapt to changing business conditions, they add more and more rules to their software systems. This accumulation can lead to several problems. Vishnu suggests some ways to address those problems with business rules.

A way to record business rules - Examples

Examples are concrete descriptions of the expected behavior of an aspect of a solution using real-life data. Examples are useful for describing a solution and providing guidance on ways to validate it. Using examples to describe a solution is also known as specification by example, behavior-driven development (BDD), or acceptance test driven development (ATDD).

There are two common forms used to convey examples. Both forms arose around the needs of automated testing frameworks.

The first format supported Fit, the Framework for Integrated Test. The intent was to enable stakeholders to provide examples in tools familiar to them (such as a word processor), which developers could then hook up to “fixtures” to produce automated tests. The examples are formatted into tables (which resemble decision tables) in HTML files.

A way to identify and clarify business rules - Example Mapping

Example Mapping is a backlog refinement technique that helps you structure your team’s conversation around a backlog item. The conversation focuses on drawing out all the relevant acceptance criteria (or rules), related scenarios and pertinent questions associated with the backlog item you are discussing.

An example mapping session identifies:

  • Examples that can lead to acceptance tests.
  • Acceptance criteria that indicate agreed upon constraints about the scope of the story
  • Questions about scenarios where your team isn’t clear on expected behavior.
  • Assumptions you’re making in order to move forward
  • New backlog items you discover because of the discussion or sliced off and deferred from delivery.

Thanks for Reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Talk to you in a couple of weeks,

Kent J. McDonald
Founder | KBP.Media

InsideProduct

Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!

Read more from InsideProduct

I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...

I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...

For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...