The Learn-Build-Measure Business Engagement Approach

[tracyconn2022]

Eric Ries created a Build, Measure, Learn (BML) business process centered around helping lean start-up and digital product companies learn fast so they could build fast. I found Ries’ process intriguing, but his original process design did not work for my career, so instead, I made a few tweaks of my own and now operate my Business Data Analyst career utilizing a Learn, Build, Measure (LBM) business engagement process.

The process I have created is rattled with feedback loops, which not only lead to deepened partnerships within the business but also enhance our own learning and ensure we understand what the business is telling us, ultimately resulting in better adoption.

At a high level, the process I follow is a simple one:

• We LEARN first from our business partners to help generate ideas.
• We BUILD an MVP to begin further conversations and iterate the code based on feedback and the need for future enhancements.
• We MEASURE the success of the solution by using data.

Step 1: LEARN - Learn Faster: Listen to Processes & Learn the Gaps

The first step in the process, and also what I would consider to be the most critical, is LEARN, which involves listening to the business about their problems and understanding the gaps where we can assist. This step is not focused on solutioning but rather listening and prompting.

Listen to Understand; Question & Prompt

Stephen Covey stated that one of the most important things a person can do is “Seek first to understand, then to be understood.” It is not our job to immediately start solutioning. We must first understand everything the business is experiencing and why they need our help. Throughout listening to understand, I question and prompt. There may be gaps in my knowledge or things the business did not think of, whether it’s an impact on another department or integration or whether it is something small around who should be notified.

Invite Others

Sometimes during the initial meetings, people who may have not been initially consulted were missed and need to be invited. A lot of the work we do is cross-functional and can have a wide impact, so we definitely want to make sure we have all the necessary business partners included.

Identify Areas of Help

After understanding what the business is experiencing and ensuring all necessary business partners are included, we begin to brainstorm the main areas where our team can assist. Occasionally, there is more than one area that needs attention, and in cases like this, we also prioritize to ensure we are working on the most critical and impactful areas first.

Document Understanding; Internal & External Feedback

Upon completion of understanding, all of the learning and requirements are compiled into a Business Requirements Document (BRD) and sent back to our partners for review. Although this may initially seem like extra work, it is vital because it ensures our complete understanding of the business problem(s) and gap(s) and allows for an additional feedback loop. The BRD is updated with any of the feedback provided.

But the learn step isn’t finished there! We need a round of internal feedback, too. My immediate team members have extensive knowledge across the business, and conducting a review with them on what was compiled into the BRD is another way to ensure completeness. This type of internal feedback loop could provide additional questions that need to be taken to the business.

Step 2: BUILD – Code Faster: Build MVP & Iterate Using Feedback Loops

The second step is BUILD, which involves building out a Minimum Viable Product (MVP) based on the information within the BRD.

The MVP is tested internally first to ensure functionality, completeness, and accuracy and then is communicated to the business. After the solution passed our internal testing standards, we scheduled a meeting with our business partners to walk through the solution and the logic. It is important for the business to test the MVP rigorously as they are closest to their use cases and can quickly identify any missing pieces. If the business’s tests are successful, they approve the MVP for release. If their tests are not successful, we seek out additional feedback, resolve the issues, and retest until the solution successfully passes business expectations.

After the solution has been approved, our team writes up a release document in the form of a newsletter that highlights what is coming (MVP release name), why it is coming (problem, business use cases), what the impact is (process or system impact), and where to find additional help (who to contact). Depending on what the solution is, we may include a process flow chart as visuals seem to help our business partners more than following a lot of words. Our newsletter is sent to our stakeholders for review to ensure alignment and capture feedback on anything that was missed or should be added. Again, since our stakeholders are closest to the business use cases and problems, they will have the best view of whether the newsletter makes sense and is meaningful to the extended audience.

The extended audience for the newsletter is determined and agreed upon with the business and communicated via email. This extended audience communication aids in capturing additional questions business users have about the solution, potential gaps in the solution from added knowledge, or the need for future enhancements or new solutions.

Step 3: MEASURE - Measure Faster: Collect Qualitative & Quantitative Data

The last step in the process is MEASURE, which is all about showcasing the benefits of the solution to our business partners as well as a wider audience. In almost every solution our team releases, we create log and notification tables that provide us with the quantitative data we need.

We then provide this quantitative data to our business partners to get qualitative responses. We utilize the qualitative data to make additional code updates and determine potential iterations or releases needed or other stakeholders that should be consulted in the future.

Benefits of LBM

When this process is carried out correctly, the business reaps extensive benefits, and things move more smoothly. However, if using this process, it is critical that the constant learning and feedback loops are fed into the entire process. There are four key outcomes you will see if implementing this process properly:

• One of our team’s internal initiatives is to go beyond the project and really learn our domain areas so we can build the deepest partnerships possible. This process, when carried out properly, will turn your business partners into strong and loyal partners who feel empowered and listened to. You will also see an uptick in meeting participation and engagement.
• Deepened partnership leads to improved trust, but so does continuously reaching out to business partners. Reaching out to business partners to see how/if the solution is still working for them and if there are any business process changes that need to be factored into the solution helps our partners trust us to stay on top of things and implement new functionality and logic, quickly, to avoid downstream impacts and reduce manual efforts.
• Staying relentlessly focused on understanding the ins and outs of the business process and the technical implementation allows us to seek out additional solution enhancements or current solution bugs, where we can iterate on them at a quicker speed.
• All of this leads to time savings. Having a great partnership with the business and a deep understanding allows us to learn faster, build faster, and measure faster.

If I did not use the LBM business process lifecycle, I would not have the partnership, trust, and domain expertise that I have today, allowing me to support my business partners and company in my day-to-day role. Leveraging a business engagement lifecycle full of constant feedback loops has ensured a deeper understanding of the business problems, domain areas, and a better solution.