Using Behavior-Driven Design to Gather Effective Analytics Requirements

More than ever, organizations are embracing the benefits of becoming more analytics-driven, understanding not only what has happened in their businesses but also what could happen next.

Whether your company is just starting that journey, or whether you’re ready to move to the next level, you’re probably wondering about the best path forward.

At Innovation Summit 2023, Mike Lampa, Chief Analytics Officer for HIKE2, addressed this exact question with his presentation on establishing an analytics program as a value stream.

Mike stresses that it’s essential you kick off the right way and then continue driving out requirements using design thinking and behavior-driven design techniques.

He presented an overview of his approach to analytics first to get everyone on the same page.

Tackling A New Analytics Program

Mike recommends you approach any new analytics program with a lean, agile product management mindset. Whenever you’re building data and analytic products, they need to be holistically designed — not only when it comes to structure and context but also access, privacy, and ethics controls as well as access methods.

If a company doesn’t already have an analytic portfolio or program in place, Mike starts with discovery planning workshops.

The team will identify the first product they want to build, whether it’s marketing analytics, campaign analysis, etc.

The goal at this point is proof of concept. You want a minimum viable product (MVP) that you can deliver in 4 to 6 weeks. You’ll prove out the whole process, including the new techniques, technologies, and skills.

Once you’ve shown you’re generating value, you’ll do an executive readout including what was learned, what was fine-tuned, the promising results, and the requested budget for the rest of the program.

After you’ve rolled out that first product, you can move on to the incremental delivery of subsequent products.

Starting Off Right with Analytics

Mike emphasizes, “Always make sure that your analytics plan is linked to your organization’s strategic initiatives.” That means:

• Identifying your main objectives. Do you want growth or higher profitability? Maybe you’ll focus on working capital – accounts receivable, accounts payable, inventory and lowering costs. Whatever you decide, know what analytics the functional domain owners, like the marketing and sales teams, will need to support those initiatives.
  
• Assessing your current analytics capabilities. What skills does your organization have? What do they need? Building the training is part of delivering the product releases. Don’t assume anything.
  
• Adding in any SWOT analysis you may have. What market opportunities or industry threats can you analyze and possibly predict using analytics?

These inputs will allow you to build a one-page portfolio canvas which will describe what kind of analytics you’ll build over the next 12 to 18 months. Avoid trying to do three-year strategic plans — they’re too difficult in today’s fast-moving environment. Instead, create a 12-18 month rolling plan you can revisit at least quarterly.

Decide what key analytics products you want to deliver over the next 6 to 9 months. Those will typically run through an agile product delivery schedule on a 10 to 12 week cadence.

Next, decompose. Know what capabilities and features you need to provide the stakeholders and what technologies will enable them. Make sure you have the architectural runway (enabling technologies) to stay ahead of the product delivery requirements.

Once you have your features and enablers, prioritize them. Your goal is to deliver as much value as you can, as quickly as possible. Mike recommends using the weighted, shortest job first prioritization technique.

Scope out your first MVP. Create the backlog for the actual delivery teams and you can start executing.

Finally, anticipate challenges. If there’s no strategic plan in place, you may need to come up with one. If there’s no existing SWOT analysis, you can quickly create one that focuses on opportunities and threats. If there’s a huge data warehouse that no one uses, dig into the reasons for that and get a plan in place.

A Real-World Example

One company Mike worked with delivered water management and road infrastructure solutions. They were focused on optimizing gross margin.

Initially, Mike thought this company’s value streams would be based on their product lines, water management versus road infrastructure. But the team soon realized they were really sales versus operations. Each had distinct priorities.

Here’s the analytic portfolio canvas for the operations value stream.

You can see high-level solutions and get a feel for the customer segments and sales channels including direct and indirect relationships, including high-level objectives and key results (OKRs).

One of this company’s biggest challenges was that their utilization of plant personnel was suboptimal. They couldn’t properly “peanut butter spread” orders to the plants.

Mike helped them identify their enabling technology partners and created a bullet list of activities to enable these solutions.

Next, they outlined what would be demanded internally to make sure that management understood the extra work involved.

As details came in, they laid out some of the metrics so that even at a high level, they could get an idea of the returns we expect for this kind of investment.

Finally, they set goals. The most difficult part is always nailing down a number. How much did the company want to improve gross margin and by when?

The team outlined what process optimization would look like and came up with high-level outcomes to target as well as some leading indicators they could use to determine whether their production numbers were improving.

Weighted, Shortest Job First Prioritization

There are many approaches to prioritization, but in Mike’s experience, weighted, shortest job first technique works especially well. Here’s how to use it:

1. Ask the business community — relative to all the other features on your list, which one has the lowest business value? Give that a one. Which has the next highest value? Give that a three. Use a Fibonacci scale, just like in agile story pointing.
   
2. Look at time criticality. Which project can wait the longest? That gets a one. Which one has to be done ASAP? Rank that highest. Any projects that are somewhat timely will fall somewhere in the middle.
   
3. Finally, rate projects that must be done for risk reduction or to enable an opportunity.
   

The total value to the business is the sum of these three ratings. It’s sometimes called the cost of delay — here’s the value you forgo when you postpone the delivery of the product.

Separately, ask the technical organization to do their own ranking.

1. Which project has the least number of unknowns or the straightest path to delivery? Which one are you sure is simple and can be easily knocked out? Give that one.
   
2. Using the same process, what are the next hardest products to deliver?

Then divide the cost of delay by the job size to get your weighted, shortest job first score.

Take the highest sorted descending score order, as in the example.

The first project, ranked at a 53, was a no-brainer for this company. They knew they could deliver major value quickly. Other projects were assigned more reasonable rankings.

This approach helped the team set clear priorities and make recommendations. They agreed to build that MVP.

Once you understand this context, you can move into behavior-driven design.

Identify and Drive to the Organization’s Need

Here’s where we all face the same age-old problem — the limitations of verbal communication. The business knows what they want, but our technical people need to clearly understand the business’s needs.

Mike recommends a combination of design thinking mindset and behavior-driven design techniques to tease out the specific analytic requirements.

Design thinking is all about discovering the need and driving to it. Be really diligent until you understand the end user’s or stakeholder’s needs, whether that’s an external customer for your analytics-enabled products or an internal customer like marketing, sales, customer service, finance, etc.

To really understand the problems and opportunities, Mike uses empathy interviews.

Everyone can tell you their pain. As you collect pain points, you can start to see opportunities to overcome them.

Craft the problem statement until everybody’s aligned.

Introducing Behavior-Driven Design Thinking

Once you move into the design phase, you’ll use a very iterative approach, trying mini-designs to see if you can move the needle and learn quickly.

Mike likes this simple, five-step framework.

1. Understand the need by empathizing with the stakeholder.
2. Create the problem statement.
3. Ideate various solutions.
4. Build prototypes.
5. Test the iterative designs you come up with.

“What I like about this approach is that it’s a software development technique. It’s typically used for building applications — operational applications, user interfaces, databases, anything like that. But it’s a recipe: given a certain situation, when you can give me an insight, then I can take an action.”

– Mike Lampa, Chief Analytics Officer at HIKE2

Embracing Behavior-Driven Design in Your Organization

Mike would love to see more organizations using this approach to establishing and growing their analytics programs and capabilities.

As he observed, “We did a very informal poll on LinkedIn to see how many of our followers are using behavior-driven design, and only about 33% responded in the affirmative. There’s lots of opportunity for growth.”

If you’ve been wondering about your organization’s next step in your analytics journey, a behavior-driven design approach may be just what you’re looking for.