How to use examples to understand your product

I’ve talked before about how helpful creating examples can be to build a shared understanding of how your product should behave – example mapping.

This week I had another reminder about how helpful examples can be. This time it was getting things back on track when I didn’t put examples together earlier.

I once worked with a team to build an application that incorporate data from multiple sources to provide product catalog information to a variety of consumers.

At one point we talked through how to process updates from the source systems to make sure that we were properly maintained a version history of changes.

After about 20 minutes of talking through things, it occurred to me that the discussion would have been much clearer (and shorter) had I created examples to refer to prior to the discussion.

As with planting trees, the best time to create examples is when you’re initially trying to describe some new functionality. The second best time is when you’re in the midst of the discussion.

So I fired up Excel and started writing out different scenarios along with the key data fields that were relevant for keeping versions. (I started this while the rest of the team was having the kind of meandering conversations that happen when a product team is trying to solve some programming problem.)

After a few minutes I shared my screen and talked through the different examples. We quickly agreed on how we wanted to address different scenarios and the team had a much clearer understanding of how to accomplish versioning.

And while I could have created the example ahead of time, I think creating the specific example as we talked was maybe even more helpful.

So here are some resources on how to use examples to understand your product, why context plays a part in the format of those examples, and how you can use an old familiar tool – the spreadsheet – to apply examples in a helpful way.

Take a look at these resources to avoid being someone that walks around with a hammer all day thinking everything looks like a nail.

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.

The use of examples to describe a solution is also known as specification by example, behavior-driven development (BDD), or acceptance test driven development (ATDD).

How to build shared understanding with example mapping

One of the primary responsibilities of business analysts, product owners, and all other product people is to build and maintain a shared understanding of the outcome your team seeks to deliver.

Conversations are an effective way to build that shared understanding. A technique that you can use during those conversations is ​example mapping​. This technique helps you structure your conversations and build a shared understanding around how a system behaves in interactions with your users.

The tragedy of given-when-then

​Chris Matts​ reflected on his 25 years doing analysis and helping others do analysis and ​points out that examples are extremely helpful for building an understanding of your product, but you need to make sure you use the right type of example for a given context.​

He points out that while given-when-then is extremely helpful for understanding interaction, it’s lousy for trying to understand the calculations that go on in a system. Furthermore, while example mapping is a helpful way to structure conversations to identify key interactions, it’s not the end of the game.

Using examples to specify calculations

To get an idea of how you might use excel spreadsheets to specify calculations, you can read this article that ​Chris Matts​ and ​Gojko Adzic​ wrote which goes into more depth about a project where ​Chris modeled calculations in Excel in order to provide a specification for his team​. This project is the one that Chris mentioned in the previous article.

Framework for Integrated Test (FiT)

If you’re looking for another example of how you might use a spreadsheet to specify calculations, take a look at ​this description of Fit written for product people​. Although the intent of the instructions is to put specifications together in order to support automated testing using the Fit tool, the specifications themselves are just as useful even if you don’t use Fit. The best part of this article is the payroll example it shows, which should provide a clear idea of how you can use a similar approach to help explain the calculations your product performs.

Thanks for Reading

Thanks again for subscribing to 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 next time,

Kent