Is Your Product Strategy “Digital” Enough? Part 1: Symptoms

Symptoms

There is no single “right” approach to developing a product strategy. What makes an effective product strategy varies by industry, business model, stage of business, etc. It’s also a given that a business’s digital strategies will likely need to address areas beyond product strategy.

Many business leaders could confidently answer “yes” to the question posed in the title and justify it by listing out the products and services they think qualify as digital. All this really tells us is that they have digital products as part of their offering. It doesn’t tell us if and how digital has influenced their approach to a product strategy.

The challenge is that “digital” implicitly means that there will be things that need to be accounted for in a product strategy, things that weren’t necessarily considered relevant before. Digital, as a concept applied to business, means that value creation and customer engagement increasingly relies on software and/or software-enabled hardware. Software, as a way to create value, also has different economics than analog value creation.

And like most things associated with technology today, change is constant. The way software is approached, what it can do, and the process and resources needed continue to evolve. A product strategy is sufficiently “digital” if it understands these points and makes clear the key assumptions being made on these new kinds of issues.

Some might push back, arguing that it’s not product strategy’s role to define tactics, and it’s better to iron out the planning and implementation. However, it probably won’t be better if this outlook enables a culture and a dynamic in which product managers are forced to address broader issues solely based on what makes sense for their own narrow context. It also probably won’t be as successful an approach if it increases the odds that you will need to implement fixes and address issues very late in the game, where the costs and risks are higher (or the budget is gone along with unmet milestone deadlines). If an issue is relevant or applies to all products, but it is not to be addressed in the product strategy, then where and when will it get addressed?

Often there is too big a gap between what is covered in the product strategy and what is required to enable quality and efficiency throughout the product life-cycle. The good news is that just because a strategy is lacking doesn’t mean there’s nothing to be done about it. To address the situation, business leaders and those tasked with developing and implementing the strategy need to be on the same page, as far as understanding what the symptoms of an incomplete product strategy are, and how and why to deal with them.

Symptoms that a Product Strategy is not "Digital" Enough

One of the qualities often associated with digital is speed. As a result, product organizations are often struggling to increase productivity, quality, and efficiency all at the same time, while inheriting strategic directions that might not be fully actionable. There will always be issues and fires to put out, but if the root causes are misunderstood, attempts to fix and accelerate forward may result in the increase of issues and the spreading of fires.

When symptoms resulting from a static strategy are not recognized as endemic to the strategy, they are seen or treated as if they are confined to a specific product context, and solving for that context will fully eradicate the problem. (Smart money bets that it won’t.)

Symptom #1: The product strategy doesn’t anticipate/address the relationship between products and platforms

Just as there are many ways to frame a product strategy, there are many ways to define “platform.” That said, a common approach to developing today’s digital products and services is to create a broad set of capabilities that can be combined/orchestrated as products or services that can (1) be taken to market, (2) be made available to partners/customers through APIs, and (3) be used by the business itself to increase productivity. This is the basic premise of many approaches to digital business, and it is a core plank of a platform business strategy.

When a platform-approach is not well articulated and accounted for in a product strategy, then the strategy is subject to interpretation and evaluation in terms of products and features. This can lead to confusion and mistakes in how capabilities of the platform and individual products and features get prioritized.

Simply put, if a product or feature relies on a capability, then not having that capability means you can’t deliver the product or feature until you do have it. The prioritization of capabilities directly influences the products and features they support. As a result, the approach to the platform affects all products supported by that platform. It’s not uncommon to find businesses making substantial investments in “platforming” their products, yet product managers and platform architects don’t consider their domains as having significant overlap or interdependence. As such, the business measures progress based solely on product progress.

This lack of common conceptual ground isn’t just inefficient for product managers and teams tasked with delivering products. It can also affect platform development in how microservice architectures are approached. If service decomposition is too tightly coupled to today’s products, it can compromise the future flexibility of the platform.

Misunderstanding the platform-product relationship can also affect the approach to data implied by the product strategy. Without any guidance otherwise, different products may take different approaches, often without a common data model. Data for operational needs may be approached as yet another silo. Products that serve global markets also need to comply with multiple variations of local regulations. With data being a key component to the value of a platform business strategy, not having data addressed or reflected in a product strategy can be a costly oversight. It’s also not a good sign if a separate data strategy exists and it is not reflected in the product strategy.

Symptom #2: The product strategy doesn’t anticipate/address the relationship between changes in products and changes in process

While a product strategy doesn’t need to define the process to be taken on a per product basis, it should reflect the range of processes that the product organization will need to support. And it should anticipate if new products will require new processes.

If there is logical alignment between product, requirements, and process, using the right process increases the odds of success. If new processes are to be used, the biggest risk is people being unaware of the implications to their tasks. If they are an input to the process, or if they don’t provide the right input, the process effectiveness gets compromised. If they are a consumer of the output and they don’t get what they expected, they may disregard the output and do it themselves — and then the process is considered to be a waste of time and resources.

There are many ways to approach product development (user centered design, design thinking, lean UX, MVP-based product evolution, agile, scrum, Kanban, automation, etc.). Product managers may opt for a process that deals with risk and uncertainty by not overinvesting in features or use cases that haven’t been validated as providing real value to real customers. The idea is to get something out early and validate assumptions and next steps based on feedback. What is often missing is how this round trip will be done — what data will be collected, how it will be collected, how it will be analyzed, how the outcome will be used to inform ongoing efforts, etc. In the case of platform-based products, it is simply inefficient for each product manager to develop their own approach to data.

As processes evolve, so do the tools, artifacts, and ways of working. Often this evolution is driven by the opportunity to provide benefits and efficiencies across product development efforts. Examples of this evolution include design systems, UI/UX pattern libraries, and approaches to templating and componentization. To be most effective, these tools and artifacts need to be developed and evolved with input and evaluation across functions and stages of development (versus simply rising from the detailed development of a single product). In fact, if a tool isn’t a component of the product strategy, it may never fully come about or serve all the products.

Localization of products often happens after the product has achieved a degree of completion or maturity. Localization may simply mean a version of the product where certain aspects of the UI are different in order to account for differences in language. Many products will require deeper degrees of localization based on the differences in cultures and cognitive approaches of users. In some cases business rules will require substantial changes (e.g., which features might be available, how a product is purchased, how it is supported, etc.). A product strategy should at least indicate which products will likely require localization and how deep this localization might be in certain markets that are key to the success of the strategy.

Symptom #3: The product strategy over-emphasizes innovation but doesn’t adequately define what is meant by the term

While a product strategy needs to be forward-looking, simply calling everything it covers or implies an “innovation” can create problems. This is especially true if business stakeholders have one model of what innovation should mean and the product organization is faced with real constraints that produce a very different model that is not aligned with stakeholder expectations.

The product strategy should provide the context for defining innovation and expectations around innovation. This allows those tasked with implementing the strategy to make the right choice of process and set expectations for outcomes without being blind-sided by stakeholders applying very different expectations when evaluating the outcome. The point is not to drive innovation out of the products or the product strategy, but to make it much more explicit by what is meant and create a common understanding of what innovation means.

If your goal is to deliver innovation through improvements to existing products for existing customers, but your approach is geared towards disruptive or ground-breaking innovation, it’s highly possible that the outcome might be a version of the product that doesn’t fully cover the existing needs of the customers. Or it might require changes on the customer’s end that they aren’t willing to make.

The product strategy doesn’t need to define the ideal fit between product innovation and market. Experienced product managers know these issues. But they are not always in the driver’s seat of the product strategy. A product strategy that clarifies innovation helps product managers better frame assumptions and requirements around product adoption that should be factored into product definitions and product development. 

Symptom #4: The product strategy refers to design only in the context of a role, or a specific stage of product life-cycle development

Design is both a process and the output of the process. Simply put, a business that sees design as role and constrained to a particular stage, is really saying design is only about the output. This is an indicator of low design maturity. One of the risks here is the belief (or expectation) that design will increase the overall effectiveness of the product simply by “finishing” or massaging and filling in around decisions that they inherit. While it is certainly more efficient to have design function this way within a fast-paced product organization, it’s unrealistic to think that design can fix a bad or poorly informed decision.

Design maturity means acknowledging and understanding how the quality of design output is tied to how well design processes are integrated in other processes (e.g., strategy development, product definition, innovation). It also recognizes that there’s usually a benefit for businesses and customers in having products share common characteristics in terms of quality and character of the user experience (e.g., single sign-on across all products).

Design maturity also recognizes that different design problems often intersect, and that a designer in one area of focus may not have the tools and experience to be effective in another area of focus. A product design team may own the customer experience for the product, but it’s very rare that the same team can address the overall experience the customer has across all products and all stages of doing business with the company.

Conclusion

Every business has the unique challenge of defining what digital means to them, and what it means to the products they bring to market. One of the most important things a business should understand is this: as the business becomes more “digital,” the product strategy has to reflect that shift. It must provide more explicit direction or guidance on issues that will affect all products but can’t be fully solved as part of the development of any individual product.

Part 2 will look at some ways to improve a product strategy that is in play but wasn’t born “digital.”