Agile transformations are often initiated by production teams that believe Agility will empower them to deliver better products in a shorter time. Organizations speak of “faster time to market” and “higher quality.” They look at the cost and green-light the proposed transformation.
Reality is that often these teams successfully decrease their delivery time without really improving the way they think up their products, that is to say, Product Agility. And faster delivery of poor products is still a losing proposition.
The main value of an Agile transformation is the ability to react quickly to complex market conditions, and this includes turning a losing proposition into an award-winning product. The story of how Design Thinking helped Airbnb make that exact transition is a classic example. Not helping your teams to achieve Product Agility takes away the main benefits of your transformation.
Here, we will outline three impediments to Product Agility that are often encountered in organizations and explain how to overcome them.
1. Not having user-centric product management practices
In traditional organizations, product management decisions are often based on long-running assumptions about users, such as believing, like Kevin Costner, that if you build it they will come.1
Product plans are made several months ahead of time for budgeting reasons and are rigorously monitored to remain on scope, on budget, and on time. In the conversations, we hear more about “projects” and “resources” than “needs” and “users”. In fact, nowhere in the process is the user involved.
As each assumption carries the risk of being wrong, the likelihood of reaching a product/market fit is not improved by the transformation.
Here are three tips to help refocus product development on the user:
- Stop talking about projects, which is a way to track work units, and start talking about products at the service of real users.
- Refrain from talking about features and solutions until the very last moment. Instead, talk about users, needs, and value.
- Most importantly, include the user in the conversation. Remember the old telephone game where a message is carried over a string of individuals, one after the other. The end message is never the same as the original one. The same applies to the understanding of users’ needs. Having nonusers relaying information to the team working on the solution carries many assumptions. To avoid this, direct contact with the users is needed. Some approaches mention bringing the user into the team, others encourage the team to go “out of the building” and to wear the user’s shoes. In the end, we want a collaboration that enables us to better understand what needs to be done.
2. Not validating hypotheses
An assumption is believed to be true, while a hypothesis is no more than a guess. In The Four Steps to Epiphany, Steve Bank identifies various categories that regroup the hypotheses that we make while developing a solution and that should be validated.
- Customer Hypotheses: Do we truly understand the motivation, needs, and pains of our customers?
- Solution Hypotheses: Does our solution solve the problem? Is it used? Is it accepted?
- Channel/Pricing Hypotheses: Is the business model viable? Have the projections and the distribution hypotheses been validated?
- Demand Creation Hypotheses: Have the messages and the marketing assumptions been validated?
- Market and Competition Hypotheses: Is the market reacting according to your expectations? What about your competition? Any legal challenges?
Only through short cycles of hypotheses and validation do we really understand the market, the product’s value, and its users; they allow teams to make better product management decisions. Organizations need to support Product Owners in validating their hypotheses as quickly as possible.
It may sound like common sense, yet many organizations find it difficult to track the impact of their team’s work. And as it is easier to track the cost of a team, it becomes natural to make investment decisions based on cost more than ROI.
To efficiently validate hypotheses, organizations must help their Product Owners.
Tracking the impact of work done
For any type of product, Product Owners will want to validate if and how it is used, and by whom. Mainly, they will want to know if the work done produces the projected value (the hypothesis) and what impact the work had on the organization’s metrics.
Several metrics models can help organizations get started. Scrum.org suggests a series of metrics for its Evidence-based Management Practice. The metrics are intended to measure the impact of the transformation, including Product Agility. They can be used to validate what is most important for your organization and define ways to measure the impact of work done.
Another model introduced by 500 Startups is often used in Lean startups: AARRR or the Pirate Metrics! The model suggests to track every product touch point, as per the customer’s journey. For example, using this model, you could measure the impact of a new press release on SEO, and follow it through the full customer life cycle.
The organization may have to adapt some accounting and customer relationship management practices to allow monitoring and be transparent about its numbers.
Validating each hypothesis in itself
To gain the knowledge we seek through hypothesis validation, Product Owners must be able to validate one hypothesis at a time. This poses a few organizational challenges.
Traditionally, organizations aimed to create “big bangs” where, in a single day, they would do press releases, press conferences, and interviews, start ad campaigns, and deliver a large product increment. The goal was to get word of mouth in a non-digital environment. Today, you may want to consider a more granular approach where you can validate the impact of each hypothesis. You can find that a message works better in a market and less in another, or you can find that a feature is used for a different reason than what is shown in an ad. Each finding is a hint toward a better market/product fit.
To achieve short validation cycles, teams need to have their organizations’ support regarding investment in enabling technology and technical debt payment. Organizations should review those costs with the end benefits in mind. For instance, to receive rapid market feedback, some teams may want to invest in continuous delivery technology, while others might want to invest in architecture refactoring.
Product Owners may propose new tools, such as A/B tests and feature toggles to shorten the feedback loop or to limit the test to a small portion of your market. As an organization, you may want to review your team’s needs and support upscaling of such tools.
Finally, you can use prototyping to test some hypotheses. They can be quick, using only paper and pen, or more complex using a semi-functional interface. While prototyping is a great way to quickly validate hypotheses, it is recommended to remove the prototype once the test is completed. If the solution is validated, build it according to your quality standards. Should you make additional tests or add new prototyping elements over the existing prototype, you may run into some of the following issues:
- As the prototype still carries assumptions that can be wrong, building new tests over it increases the risk of not validating your hypotheses correctly.
- As the prototype is an unfinished version of the solution it represents, there is a cost to completing it. By adding new tests or prototypes over it, you are compounding that cost. This is called the “technical debt.”
- Often, prototypes do not meet quality norms, as opposed to regular features. They may not be as robust and may be more prone to defects. Building on them may decrease your ability to develop better and faster.
- Keeping elements of that solution that have not been validated “just in case” creates added complexity to both the code and the user experience.
3. Not understanding the Product Owner
The role of the Product Owner is to maximize product value. It is not always clear what this means for an organization. We found that in many situations, this role is confounded with that of a Product Manager, Business Analyst, or Project Manager. Not understanding and supporting the role of the Product Owner may cost the organization the loss of Product Agility benefits.
Decision-making
Product Owners should be empowered to make any decision regarding the product, including ceasing its development. In traditional organizations, it may be difficult to delegate such authority. In an Agile environment, use transparency and collaboration to help and support your Product Owners in their decisions.
As an organization, you should trust your Product Owner to learn from their own mistakes, not yours.
Empiricism
Product Owners believe that experience is the best source of knowledge and that decisions are based on such knowledge. There is no fixed plan on the table, and definitely no Gantt chart. They are zealous about measuring everything. Their plan can change periodically.
As an organization, do not tie your Product Owner to a fixed plan and understand that the complexity of software development is such that it is very difficult to accurately predict delivery dates for a specific scope.
Collaboration
Product Owners believe that collaboration creates better products. They seek to bring together all the product’s stakeholders to review product increments and to plan. They use tools to make all the data and decisions visible to everyone and openly ask that anyone who may have a positive impact on the product get involved.
As an organization, help your Product Owners by supporting their stakeholders, including the product users.
They possess more empathic abilities than management skills
Product Owners must be able to breathe the same air as the users and share their pains. Their core function is to optimize the product’s value by ordering the work to be done. They focus on the problem space and product value.
As an organization, do not ask the Product Owner to constantly complete a progress report, review job status, or evaluate “resource” performance.
Today’s organizations compete on all levels: marketing, recruitment, products, services, financing, and so on. Achieving Product Agility becomes a key benefit of digital transformation.
1 Field of Dreams (1989), http://www.imdb.com/title/tt0097351/
No Comment