Four Ways to Enable Product Recommendations from Technical Experts

Receive free IIBA updates and exclusive content!     Join Now!

Software products are shaped by two yin-yang forces: business needs and technological capabilities. While business needs usually lay the foundation for a product, technological capabilities enable, transform, and restrict features. How can a product team effectively involve their technical team in product decisions without swamping them with discussions and business analysis work?

There are processes that partially address this question, such as backlog refinement in agile development, IP iteration in SAFe and design sprints. They are well covered in the professional literature. In this article, I want to focus on additional practices mentioned less often and which I find useful from my experience as a member of a product team.

Simplify Solution Requirements

After gathering stakeholder requirements, the product team analyzes and organizes them into the solution requirements to start collaborating with technical experts. While we should involve technical experts at the early stages, we should not present messy incomplete data to them. Diagrams are a good way to identify excessive complexity and gaps in the requirements. If a diagram turns out to be too complex, there is usually room for logic improvement and simplification.

Some time ago, I was interviewing end-users and they were requesting multiple statuses for a business entity. My first attempt to organize all the statuses into a lifecycle was a diagram with about 20 statuses with a lot of transitions among the statuses. It was a half-year project for a single team. Large complex projects can have complex lifecycles with compound states, but it was a relatively small one. I reviewed the statuses and noticed that majority of them were just tags for search, not full-fledged statuses that define which actions can be performed and who can do them. So, I simplified it, and the final version of the diagram had 4 statuses, and each status had a set of search tags.

Even when I am not able to simplify the solution requirements myself, the attempt to solve the simplification puzzle is still useful, because it usually helps me to identify the “missing puzzle pieces” and discuss them with stakeholders before consulting with the technical experts.   

If we do not overload technical experts with messy complex incomplete requirements, they have more time to help us, even with technology-agnostic puzzles that we cannot solve on our own. So, it is a good practice to search for the simplest requirements that address the business problem.

Be Fact-Ready, Know the Problem

A product team collaborates with technical experts on multiple levels – solution, feature, backlog item. Regardless of the level, we need to be fact-ready and know the problem.

When eliciting requirements from stakeholders, it is better to focus on their problems and how they solve them now, not their future solution ideas. There is an excellent book on this topic – The Mom Test. When you ask a technical expert to help you with the puzzle, you should be ready to provide the context and facts you elicited from stakeholders.

Besides eliciting information from stakeholders, there is another important aspect of fact-finding – artifact analysis. Artifact analysis includes studying an obsolete solution to be replaced, reviewing support tickets, looking at similar solutions existing on the market, analyzing input files that are going to be ingested by the solution, and other activities depending on the project type.

Several years ago, I was working on a relatively complex project that ingested data from multiple sources. We were under time pressure, and there was a temptation to rely on the elicited information about the data inside the files, but we still decided to look in the input files. We were glad we did. We found a hierarchy that we did not expect, the structure of data was somewhat different from what we expected and there were multiple duplicates to resolve.

It seems obvious that the product team must fact-check the main artifacts. Time pressure might tempt us to skip this activity; however, it will cause more time to be lost in fact-less meetings. Furthermore, artifacts analysis is usually not as tedious as it seems.

When you have a fact-checked problem statement, you will be able to find a better approach for the solution/feature/backlog item with the technical experts.

Advocate for the Best Ideas

Well, you have simplified the requirements, collaborated with the technical experts, and defined the approach. You should still be open to constructive criticism.

On one of my projects, I worked with a brilliant technical expert, and we came up with a good solution. However, in a backlog grooming, one of the team members suggested a better one. We thoroughly assessed the change, and it did not imply any additional risks, was significantly simpler, and provided the same business value. Of course, we had to rework the product requirements and the high-level design, but we knew it was worth it – the approach was much simpler in development and later on in support.

Sometimes, you might need to advocate for an idea within the product and business teams because it implies some limitations on the user side, for example, configuration through files instead of admin UI. Before you present an idea to the business team, you need to thoroughly assess the risks, fact-check the rationale, and consult with SMEs. It is similar to the argument above about knowing the problem, but with the information flowing the opposite way: it is about knowing the alternative solution and why it is better when you present it to the business team.

Educate Yourself on Technology

The product team should know the solution technologies and design approaches to understand technical experts and communicate effectively with them.

For example, when I was working for the first time on requirements for a cloud-native application, I had to learn a lot about the cloud-native approach, AWS services, and other related topics. In the beginning, it was tough, but in a couple of days, it got better. After the artifact analysis, I started working together with a technical expert to define components based on the usage patterns so that they could scale independently. I still had to ask for clarifications about the technology. However, I did not experience informational overload, and I was able to understand the technical expert. 

The example above is about collaboration at the design level, but understanding is important at all levels. A development team occasionally asks me to add a backlog item worded in technical terms. If I do not understand the value, we discuss it together with the team. It often happens that instead of adding a new item, we split existing items and add technical details to the acceptance criteria. This process ensures that everybody on the team understands the scope and value of the backlog item the same way. Also, the team will be delivering the smaller items, and QA will ensure the quality for each of them. So, it helps to lay the foundation for the built-in-quality.

Conclusion

We all want our products to be better. The product team and the technical team are really the same team building the same product. Empowering our technical experts is particularly important. The following practices helped me in the past:

1. Searching for the simplest solution requirements that address the business problem,  
2. Preparing the facts before consulting with the technical experts,
3. Making sure the best ideas drive the product and advocating for them,
4. Educating myself on technology and design approaches applicable to the product.

These concepts are quite simple and obvious. Time pressure may tempt you to ignore some or all of them. However, skipping them will usually cause you to spend more time on ineffective communication.

 

 

---

 

About the Author

Alena Huniova is a result-oriented, innovative, and disciplined professional with over ten years of experience in software product development in an agile and SAFe environment.

References

Originally published on May 28, 2020: https://www.linkedin.com/pulse/four-ways-enable-product-recommendations-from-experts-alena-huniova/