Involve the right people

From the business side, be sure to include the following:

  • Domain expertise: Domain knowledge usually comes from product managers, analysts, and other subject matter experts (SME) whose day-to-day roles are related to the product you’re creating. They also may have an understanding of competitors, the landscape, and enterprise roadmaps.
  • Customer representation: Customer representation may play an important role if this is an outbound product, so talking to departments that service customers would reasonably lead to insights that are unavailable to senior leadership.
  • Senior leadership with visibility into enterprise strategy: Involving the sponsor and/or SVP of the business unit is beneficial because they are the buyers and ultimate decision makers.

From the delivery team, look for a product manager, group product manager, design lead, an architect, and the engineering team lead at a minimum. Additional people may be beneficial if they have something to contribute but are not mandatory.

Involving senior executives early minimizes disruptive last-minute changes later in the product life cycle.

This a very common occurrence when leaders feel left out. It can result in overcompensating by providing too much input, which often upsets the team and creates a counterproductive environment.

Here is a good example of a stakeholder team in a Lean Requirements work session preparing to build a customer portal and mobile application:

  • head of applications, primary stakeholder
  • IT project manager, primary point of contact
  • software architect, SME, technical issue resolution
  • business analyst, SME
  • execution analyst, SME
  • commercial manager, SME, primary user role

The objective is to have a productive discussion—and groups with more than fifteen people in the room are often less than productive. If you absolutely have to get more people involved—such as when building a cross-departmental custom ERP platform—adjust the workshop strategy to split requirements into functional verticals and run multiple sessions.

Anticipate and navigate around “inclusive” meeting cultures—meetings with thirty or more attendees, where the majority don’t have anything to say but are in the room because they are afraid of being left out in the cold. Establish a list of participants together with the SVP or sponsor, and then leverage seniority to push back on participants who are not critical.

Forming alliances

There are always allies and detractors in any room. Internal politics, preferred vendors, and other factors play a role. The best way to de-escalate and shift alliances is to go above and beyond expectations when the session starts. The easiest way to sway a skeptic is to introduce the session by showing we’ve done our research. Demonstrate that we understand the ins and outs of their business and the landscape.

Opportunity areas to demonstrate our understanding exist around:

  • Value alignment. Always review the organizational values and how they align with the effort. Even if the culture is not healthy, senior executives have buy-in for the organization’s values.
  • Competitive landscape and market research. Extract information about the competitors—their announcements, recent releases, news articles, and trends.
  • Benchmarking and studies. Pursue access to the organization’s applications to evaluate them and how they compare to their competitors’ apps. Our designers and engineers may be able to poke holes or identify smart decisions.
  • Technology landscape. Research adoption numbers from industry trends. Introduce the team to the above research and include materials at the beginning of the two-day agenda.
The Secret Source by Aurimas Adomavicius

About the author

Aurimas Adomavicius is the president and co-founder of Devbridge. When not in the trenches working with clients, Aurimas is an active speaker and writer on product design and engineering best practices.