#419 – HOW TO IMPLEMENT A STRUCTURE FOR DECISION-MAKING AGILITY – HOWARD WIENER CERM

In the previous article, Part I: Intent and Structure, we discussed a number of important topics:

  • What is your enterprise and what is transformation?
  • What is agility and how is it measured?
  • What is Enterprise Agility?
  • How should SWOT, OODA, OKRs, Lean Product Development and Product Discovery figure in your approach to leading your company?
  • How should you implement strategy, business model and execution decision-making layers?
  • How do you design your organization and processes to promote Collaboration and Coherence?

In this article, we will identify a number of factors that you must address if you are to achieve the agility required to sustain and thrive in your markets.  N.B., you need to address ALL of them to become truly agile.  Any piece that is missing will render much of the rest of what you may do largely worthless.  For instance, your scrum and DevOps adoption will not avail you of much if you cannot integrate it with rapid lean product discovery processes.  If you fund and manage your product initiatives with a traditional project mindset, it will not matter how quickly you can pivot on what you start out to build, you are almost guaranteed to come out with a sub-optimal product.

What an Agile Company Looks Like

Your enterprise should be product-driven and operated on a lean product discovery and development basis.  In particular:

  • Jeff Gothelf talks about the nuances of applying OKR discipline, which should inform how you think about your strategy,
  • Marty Cagan prescribes product management teams of three people, including the PM, a Designer and a senior development engineer,
  • Teresa Torres prescribes an approach to continuous discovery,
  • Melissa Perri identifies the downsides of rushing to build while discovery remains incomplete and
  • In addition, I have written an article on the subject here.

See links to work by these folks and others, below.

OKR orientation is critical.  Output orientation (associated with traditional project thinking) is delusional and misleading.   Torres, in particular, addresses the idea of looking for prospective opportunities among customer problems and identifying solution candidates that might turn into profitable products.  Jeff Gothelf talks about outcomes in terms of “if we are successful with our product, what will our customers do differently?”  Clearly sales, market share and profitability are goals of any business initiative, but if you create outcomes for your customers, it’s likely, though not a given, that you will achieve something positive for your business.  Both Teresa Torres and Dan Olsen have something to say about how to evaluate product ideas and direct your efforts toward those with the highest-potential.

All three decision layers should be operating on a continuous basis and sync at a frequency that is appropriate for each.  While ideas should be accepted regardless of the layer in which they originate, your framework for coherence must be preserved.  Strategy decisions should not depend on detailed technical decisions and vice-versa; however, your organization should have mechanisms through which each can influence the others. The collaboration interfaces between the layers must work constructively or agility will be sacrificed.  These integration points will ultimately determine whether you achieve agility or not.

Decision-making authority must be distributed appropriately; guardrails are necessary but must be defined loosely and monitored and enforced with judgment.  The decision layers should not be viewed as a strict hierarchy—product ideas can come from any of them.  Coherence, consistency between strategy, product definition and delivery execution approach is a goal.  A good product idea is a wonderful thing but not unless it’s right for your company.  Should Ford or GM be interested if either of them stumbles on a great competitor to the PostIt note?  Inconsistency between a company’s business and product strategies is a potential cause of misallocated resources and can be anti-agile.

You must operate on a lean product or lean startup approach, in which you maintain developmental product portfolios and perform discrete, rapid, short-term, experimental initiatives to prove or disprove whether a potential product deserves further investment.  What you decide to invest in must be consistent with both your enterprise and product strategies.

Initial product development efforts should focus on product discovery and favor market and customer research over building.  Building is expensive compared to deriving customer insights through research and it is expensive to refactor software when elements of a solution you started building based on assumptions are invalidated by new knowledge.  Premature investment in construction often creates resistance to refactoring in response to information surfaced downstream and this can result in impairment of product or solution quality.  (See my prior article on this subject here.)

Finally, you must be open to evolving your organization and your processes continuously.  Whatever you are doing at any point in time may be invalidated or superseded by developments in technology or the marketplace and persisting in an approach when it ceases to enable your competitiveness will only hold you back.  Change is uncomfortable, but the need to accommodate it is, and will increasingly be, a fact of life.

How Do You Get There?

The evolutionary path you take to achieve Enterprise Agility will be specific to your company and your people and will be determined by where you’re starting from.  Careful prioritization and risk management will be necessary to improve your odds of succeeding.

The following will be required:

  • Establish your decision-making framework including each of the three layers. Implement an organization model that assigns roles and responsibilities to each of the layers and implement processes that encourage and enforce collaboration among them in order to accelerate product discovery and achieve coherence.
  • Adopt OKR discipline to Inform business strategy formulation and product management decision-making and to guide product discovery and development decision-making.
  • Migrate from periodic planning and decision processes to continuous ones to the degree that it is possible to do so.
  • Jettison traditional project-oriented funding and management approaches; focus on outcomes, not output.
  • Adopt lean product development paradigms; adopt experimental, incremental product discovery and development approaches.
  • Focus on improving the performance of each decision layer independently and all of them collectively.
  • Install and promote cultural and leadership norms that encourage people to collaborate constructively and contribute outside of their formal job roles.
  • Rethink your reward and compensation structures to reinforce desired behaviors and
  • Prepare yourself to undertake a journey of perpetual evolution; you will need to be prepared to evaluate, assess and change as you determine what works and what doesn’t and how you can improve.

Some Things to Consider . . .

Given the daunting percentage of product ideas that are, ex ante, just wrong, it makes no sense to create funded projects for them with fixed scopes, budgets and schedules.  Experienced Venture Capital firms expect more than 80% of their investments to fail completely, and they are arguably more likely to be able to identify good prospects than you are.  Given this reality, you should fund initial discovery for what you think is a good product idea without waiting until you fully understand what the product is going to be.  However, you should de-risk your investment by focusing your early effort on developing consumer insights rather than development.  This may represent a significant change to your existing investment funding approach, one that you will have to make in order to attain greater agility.

Market research and learning is a lot cheaper and less self-limiting than development.  Put off development as long as possible and only do the minimum you need to do to support product definition and discovery until you are convinced that you have a viable product idea.

Don’t expect to any name-brand Agile framework to make you agile; however, you DO need DevOps and rapid development tools and techniques.  While many of them identify roles for people with product responsibilities (such as Product Owner) most of them focus on processes more than product discovery and none of them seem to provide for the level of integration between the product and delivery teams that is required.  Timeboxed processes are often antithetical to the flexibility that is required to attain real agility.  Kanban-style approaches can be better but may also be confining.

Multiple authorities on agile product discovery and development advocate for three-person product teams composed of a product manager, product designer and development engineer.  The entire team should participate in research activities as all of them will have a valuable point of view as to what direction a product’s evolution may take. You should establish such teams if you do not have them already.

Agility in delivery comes from how your people work together and their willingness to depart from rigid roles, responsibilities and assignments to respond to new information as it is uncovered.  There are many good things embodied in some of the frameworks, but you should selectively adopt what will work for you and your people and be willing to evolve as your experience dictates.

Finally, you should remember that if any of your decision-making layers are operating in a non-agile manner, your agility will be impaired. (Imagine using a GPS that forced you to stop and wait for 60 seconds at each turn before it told you which direction to go in.)

Some Good Product-Focused Resources

I have learned a great deal from reading the following:

  • Marty Cagan’s Inspired defines a product criteria framework that includes: valuable (people will be willing to pay for it), useful (it will solve a problem that people have), feasible (we can build it), viable (it will work for our company as a business).
  • Teresa Torres’ Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value speaks to the importance of continuous customer engagement in your product development and evolution process.
  • Melissa Perri’s Escaping the Build Trap: How Effective Product Management Creates Real Value stresses the importance of outcomes vs. outputs and how important it is to avoid getting drawn into the many practices that obstruct agility.
  • Jeff Gothelf writes and speaks about OKRs and lean product development. His blog is here.
  • Some of the important voices in the product management and Agile spaces include: Marty Cagan, Teresa Torres, Melissa Perri, Pawel Huryn (has an excellent set of resources on his substack site), Dan Olsen, David Pereira, Joshua Seiden, Jeff Gothelf, Maarten Dalmijn and many others.

Leave a Reply

Your email address will not be published. Required fields are marked *