Enhancing Engineering Performance with Intent-Based Requirements

Imagine what your engagement and commitment to a project would be if you were asked to think critically and provide ideas. How would that compare to a project where you are just handed a list of requirements to implement? Numerous psychological experiments have shown that when individuals are given the opportunity to contribute their ideas and perspectives, they become more engaged and committed to the project's success. For example, in the famous Hawthorne studies conducted in the 1920s and 1930s, researchers found that workers who were involved in decision-making processes showed increased productivity and job satisfaction. This concept is further supported by the self-determination theory, which suggests that individuals have an innate need for autonomy and involvement in decision-making.

In this blog post, I will share my experience with the use of intent-based requirements and how it can drive more successful product development.?I’m really enjoying the book “Leadership if Language” by L. David Marquet which is inspired by self-determination theory and seems to explain elements of why I've had success building highly productive teams.?

Introduction

In software product development, the success of a project relies heavily on clear and well-defined requirements. It's a tall order to get detailed requirements right. So often, projects are delivered due to requirements being incorrectly defined, incorrectly written, entirely missing, or generally mis-interpreted. Even the simplest of products often fall foul of one or more of the above. This is because only listing out product functionalities is not enough to truly capture the essence of what a product intends to achieve. l suspect it is often assumed by the author that the reader inherently knows every aspect of the purpose of the product.?

This is where intent-based requirements and design can be transformational. By defining the user’s needs and business objectives in a Product Requirements Document (PRD), we can enhance engineering understanding, validate requirements, facilitate lateral thinking, and foster commitment from the whole team.?When an engineer knows the intention of the product, it is easy to disambiguate requirements or at least identify where they don't align and ask questions. Often, engineers can suggest ways to accomplish objectives with a fraction of the effort that may be suggested by the requirements. The MVP of a product can be derived and delivered much sooner in order to validate the product objectives.

Whole Team Engagement

Before the PRD is shared with the team, and potentially even before it is written, I highly recommend holding a brainstorming session with the engineering team to define the following two high-level aspects of why the product is being built:?

• User Needs - Who are the users and what does the product allow them to accomplish
• Business Objectives - What does the business want to achieve from building the product

On the second point, I feel it is essential to declare why the company is building the product so that everyone is clear and those objectives can be met along with delivering value to the customer.?My advise here is to be brutally honest and define the real business objectives in order to avoid speculation.

The team should be challenged to contribute these ideas from scratch, even if the Product Manager already knows exactly what they want to achieve and why they want it.

I've brought this practice with me since the days of building regulated medical devise software (SaaMD) where the FDA standards required at least the User Needs to be stated and traced to the Product Requirements that deliver upon them. Back then, the User Needs are typically made available to the engineering team. While this is a wonderful resource to understand why a Product Feature exists, it still is presented as a set of pre-defined requirements to be consumed by the developer.

Starting with a blank slate encourages the team to engage and think creatively to truly understand the objectives at hand. This approach empowers the team and makes them active contributors to the project definition. When engineers have a sense of ownership over the objectives, they are far more likely to be fully engaged and committed to delivering a successful product and usually go above and beyond.?

To foster whole-team engagement, you should employ a “silent voting” practice similar to how you play planning poker. Ask the team members to write down their ideas for User Needs on sticky notes prior to sharing them with the whole team. Repeat the process for Business Needs. This approach helps avoid groupthink and provides the psychological safety to generate original ideas. By creating an environment that values and encourages input from all team members, we can unlock the full potential of the team and drive successful project outcomes. You can gamify this session to make it fun. If the PM has a predetermined list of User Needs and Business Objectives assign a point for each one the team members identify. You can attribute double bonus points for valid ideas that the PM hadn’t thought of yet.?

If you don’t do the above, I guarantee that that several of your team members will not engage. Those with the loudest voice will dominate the session, and this will be a lost opportunity to gain new ideas and project engagement.

Linking Requirements to Objectives

Once the user needs and business objectives have been defined through the brainstorming session, they become the guiding principles for the product development process. Each requirement can be traced back to the objectives it aims to fulfill, creating a clear and logical connection between the proposed product design and the desired outcomes. This approach not only facilitates creative thinking but also ensures that every objective is met by the final product.?

Defining User Experience (UX) in Alignment with Objectives

In addition to linking requirements to objectives, it is equally important to define the product's user experience in terms of "usage scenarios" that trace back to one or more User Needs. By aligning the UX with the objectives, we create a cohesive and purpose-driven user experience that directly addresses the intended goals of the product. Ideally, the User Needs and Business Objectives brainstorm session should be completed with the team first in order to establish a strong foundation for the UX design. You should invite your UX designer to the brainstorming session.

Later in the development process, and even prior to implementation, you can define and trace verification tests to each usage scenario. I feel that the most valuable test metrics are those that verify each usage scenario is working as expected.?Contrast this to code coverage, which doesn't tell us anything about the missing code for the feature we forgot to implement!

Keeping it Concise and High Level

User Needs and Business Objectives do not need to be defined in great detail. In fact, they typically consist of less than one page of bullet points for both sections. The focus should be on capturing the essence of what the product needs to achieve rather than getting lost in lengthy descriptions. This concise format allows for easy reference and ensures that the objectives remain at the forefront of the development process.?If you find yourself writing more than a sentence for each bullet point, you're probably describing requirements instead of objectives.

I’ve found it a fascinating exercise to define User Needs and Business Objectives with the team and have needed to keep asking questions to the team and the PM to abstract the definitions up to a higher level. It’s the opposite of how “the five whys” drill down into a Root Cause Analysis (RCA). You have to? ask questions like “but why does the user want to do X?” or “why does the business want Y?”.?

The beauty of “drilling up” to the high level objectives and actually documenting them is that it provides an enduring "stone tablet" definition that enables lateral thinking. Your team members may think of radical new ways to deliver value to the customer or the business after understanding these high level objectives.?

Conclusion

Intent-based requirements and design have the power to transform the product development process. By involving the engineering team in the brainstorming of user needs and business objectives, we enhance understanding, validate designs, foster commitment, and encourage lateral thinking. This collaborative approach empowers the team and leads to more innovative and successful products.?

I hope you've enjoyed this post and I encourage you to embrace intent-based requirements and whole-team collaboration to drive impactful and purposeful product development.