The last few chapters brought your execution, decision making, and data practices to levels that enable you to manage digitally driven projects and transformation programs. You can use data-driven practices to make better decisions and to analyze customer needs. Portfolio management practices help to ensure that you have balanced priorities that target short-, medium-, and longer-term benefits. Agile methodologies help you drive execution, keep alignment, manage change, and improve quality.
Now you can apply all this capability to operational excellence and become a more efficient organization delivering higher-quality services to customers. Many organizations can drive significant bottom-line improvements through automation, digitally enabling workflows, and integrating third-party capabilities. Any organization that’s been lagging investing in digital technologies and still performs a lot of nonphysical work manually should be able to find lots of opportunity to become more efficient.
But digital transformation isn’t just about improving the bottom line. Efficiency plays will enable businesses to be more profitable and operationally competitive but still ripe for disruption from new competitive services that offer customers new choices and opportunities. Garmin isn’t going to survive by becoming more efficient while improving their automotive GPS tools given that most consumers will get “good enough” capabilities from alternative inexpensive mobile applications.
Many businesses will be able to get a lift in customer satisfaction and revenue by providing digital, self-service capabilities in their products and services. Newspapers provided subscribers with websites and mobile applications to read content and advertisers a digital medium to target customers. Banks enabled business and consumer customers with online and mobile experiences to perform common transactions. Existing retailers added e-commerce channels to sell alongside their brick-and-mortar stores.
Let’s put ourselves in one of these situations so that I can illustrate a point. You are a newspaper, and you built a website or a bank that has built a mobile application. It’s less interesting to look at how the original channel got justified and developed, and the relevant question is how has this channel been supported over the years after its initial launch. What was the organizational approach to product improvements? What level of investment was made over time to ensure that the product remained competitive? Who drove the product priorities? How were improvements measured for success?
A few patterns emerge when you consider how organizations supported their initial investments in digital products and channels:
Big bang, infrequent upgrades—Many financially driven institutions look at digital investments as onetime events. You scope, plan, build, release, and hopefully reap the benefits. If improvements are required, someone has to make an ROI case or prove there’s a competitive threat to drive new investment.
Sales-driven investments—If your product is being sold by a sales force, then many businesses become “sales driven,” and priority investments are driven by their needs. Sales-driven product priorities can be very ad hoc when the loudest or most experienced salespeople drive the priorities.
Customer-driven investments—These occur when products and services are sold directly to their consumers and there is a voice-of-customer feedback loop providing insights on their wants and needs. For example, I can go onto Atlassian’s website, vote for a feature, and hope this feedback will drive priority.
There are some benefits and weaknesses in all three approaches. Big bang investments work best in industries that are very slow moving and where disruption from new entrants is least likely. In theory, these businesses can wait for a more aggressive competitor to demonstrate what capabilities are driving success, then look to replicate.
The problem today is that fewer industries and businesses can operate with little threat of disruption. Everything is being challenged today, and if you wait too long between investments, you have a lot more work to catch up before driving any new innovations. What’s worse is that you are less likely to have the culture, practices, and skills to engage customers and develop products. Lastly, technology is changing so rapidly that businesses playing a wait-and-see game have a larger hurdle replacing legacy technologies or finding new technologies to enable innovation.
In my opinion, big bang product upgrades are a dead-end strategy at least for the next several years, as just about every industry faces some form of digital disruption.
A sales-driven strategy sounds good if you have evidence that the sales team can retain customers or drive incremental sales from the investment. There might be customer-specific requests like, “If we don’t have feature X, then customer Y might switch to a competitor, but if we do, I can get us additional revenue.” Or more generically, “I have customers that require A, B, and C.”
These requests look appealing to CFOs and CEOs who look for investments that have near-term ROI but suffer from other issues. First, the expression lacks a true understanding of customer need and value proposition, so it’s unclear whether the solution is solving a strategic long-term need or a short-term tactical challenge. Second, since the request is expressed through a salesperson, it’s unclear whether the investment and solution can scale across multiple customers. In today’s digital world, it’s hard to get a single or small group of customers to fund the upfront investment and ongoing support of any solution, so sales-driven priorities tend to drive small incremental improvements in the product.
Customer-driven strategies tend to have the reverse problem. You may be collecting direct feedback from your customer through engagement, surveys or actual product usage metrics. In aggregate, they may provide an expression of what enhancements key customers and segments want from your product, but they may not provide sufficient context to drive significant investment or change. Depending on how you collect the information, it may be difficult to ascertain whether customers are willing to spend more on the improvements, measure the urgency of the request, or capture what alternatives they are considering.
When a business or a product is operating at smaller scales, it is possible to be sales or customer driven. There’s a finite demand coming into the organization, and very often a decision to invest is driven by whether customers are willing to pay for the enhancement.
But for most products where there is a larger number of customers, discerning the true opportunities from disparate voices of multiple salespeople or directly from customers can be complicated or misleading. Even when priorities are easy to ascertain, there is still the issue of whether the enhancements developed for the needs of a few customers introduce complexities to mainstream customers or to the teams supporting the products. You can easily see this issue when applications have complex user experiences, forcing you to enter more data through more steps, and were designed to support several use cases. One way to measure this is to collect product usage statistics. Many products with long histories of having customer-driven enhancements show a few primary features with heavy usage and a long tail of secondary features used by a small minority.
Sales- and customer-driven organizations often view the role of product management as a proxy to make sense of all these needs. If the primary source of priority is sales, we often call them “stakeholders,” and if they are specific customers, then we label them “strategic customers.” One of the roles of product management is to sort through stakeholder and strategic customer needs, develop priorities, and drive organizational buy-in for implementing them.
Sales- and customer-driven product improvements are essentially bottom-up, tactical approaches employed by many companies to prioritize enhancements to existing products. There’s nothing fundamentally wrong with sales- or customer-driven prioritization so long as there is some governance in the decision making. In addition, a user experience strategy is needed so that product interfaces don’t evolve too complex experiences as new capabilities are added.
Beyond just extensions, some organizations can buy time by focusing on nondisruptive digital products. They complement existing “analog” products, and consumers will buy analog, digital, or both. For example, you can buy a print, digital, or both experiences of The New York Times or The Wall Street Journal. You can pay Netflix for DVD subscriptions, streaming movies, or both. These work well when existing businesses can offer new digital capabilities to existing customers and also attract new ones.
Although these digital products may look easy for businesses to manage internally, the reality may be quite different. The executive team first should determine whether digital product sales and support will be new responsibilities added to existing business lines or managed as separate digital businesses. Many media and retail organizations opted for the latter because selling and supporting digital is often a different skill set and business dynamic then their analog equivalent. Still there are often conflicts on branding, go-to market strategies, pricing, and sales strategy once businesses have to manage both legacy and digital. Overseeing this can be a distraction for the executive team and is one reason disruptors can sometimes come in and blindside incumbent businesses.
Product extensions and nondisruptive digital product offerings may not be sufficient to drive digital transformation depending on how fast your industry is changing and how easy it is for new disruptive entrants. In this environment, organizations must be more market driven and strategic and looking at brand-new product and service opportunities, partnership opportunities, and new investments. This isn’t easy for many organizations that have been selling and delivering the same products the same way with well-defined competitors for long periods of time.
A digital strategy reimagines a new digital business with potentially all new products and service experiences based on market opportunities, the blending of physical and digital capabilities, and leveraging emerging technologies. In this transformation, the existing business is broken down to its assets, organizational capabilities, and other building blocks. Additional building blocks are then considered, some that the organization might develop internally, others it might buy through services, and others where it will establish partners. This future “digital business” is conceived, and then leaders have the very difficult task of strategically planning a transition from a legacy company to digital business.
The executive team should form a product leadership team to develop a digital strategy and align a process to other strategic planning efforts. Who will lead the product leadership team, and who else should be on the team and fulfilling what roles? How often will this team take on planning activities? How will the plans be communicated, and what elements of the plan will be public, shared with a limited audience, or private depending on its risk of disruption. Finally, they need to consider where to bring in outside partners to aid in the research or analysis, perform tasks outside the skills of the organization, bring in tangential capabilities, or lead change management and training activities.
There’s a lot to cover under strategic planning digital transformation, so let me suggest that there are a few key tenets that organizations need to focus on to develop their digital strategy. First, product management needs to focus on strategic activities like determining target markets, quantifying market opportunities, and determining longer-term customer needs. Second, they need to conceive new digital products that deliver value to existing customers and new markets. Lastly, they need to conceive go-to markets strategies, digital marketing approaches, and sales processes to sell digital products.
This may sound daunting, and it is for many organizations that struggle with organizational change management. Therefore, articulating a digital strategy is a critical step in the transformation as becoming more of a digital business is likely to affect the entire organization. The strategy should set a future direction of the business but also provide some guidelines on how leadership plans to get there. Thus, the strategy is a communication tool to the extended executive team, employees, the Board, and selected strategic partners.
But the strategy doesn’t have to be developed top-down in an ivory tower. Also, contrary to what experts tell you, it doesn’t have to be developed as a first step before anything else can be considered. I prefer setting the strategy only after some other factors are considered, such as target markets, customer segment opportunities, and even potential products.
So, for the remainder of the chapter, I’ll break this down starting with product management’s role in digital transformation.
As stated earlier, many organizations view the product management role as a tactical role aiming to listen to customers and stakeholders and manage the product with the goal of growing revenue and the number of customers. But project management disciplines go well beyond managing everyone’s wish list. Product managers drive changes in sales process, marketing, tiering, bundling, pricing, discounting, partnerships, and enhancements to achieve their goals. The product management function is usually broken down into several key disciplines:
Product strategy involves identifying and quantifying target markets, market needs and opportunities, market sizing, competitive considerations, industry transformation considerations, economic, legal, or geopolitical factors that help businesses determine the primary opportunities for growth.
Product ownership is the role in agile practices and is responsible for setting priorities for developing or enhancing products, measuring customer satisfaction, and engaging internal stakeholders.
Product management disciplines oversee the P/L of either a customer segment, product family, or single product and drive priorities on revenue, growth, profitability, quality, and customer satisfaction.
Product marketing is the skill to define, execute, measure, and modify go-to-market strategies along the lifecycle of the product.
It is often very difficult to find product managers that have skills and experiences across all these disciplines, but the revenue-generation elements of digital transformation programs do require them at different stages in the transformation. This means organizations must consider how to apply internal resources and bring outside help in weak areas. You might bring someone from the outside to help quantify target markets and to review competitive offerings. Perhaps the organization has ill defined or outdated pricing and some research is required to determine price elasticity and value propositions. You might have a defined product strategy but need outside help to develop talent to assume product ownership roles. You may have developed a product but lack the data or marketing knowledge to market it optimally.
More importantly, it requires organizations to recognize the strategic importance of the product management function. The executive team needs to give product managers the charter and backing to review the end-to-end business and to propose blue-sky options that might include options that disrupt existing products and services. They need to blaze paths to get them access to data, ensure that business leaders are accessible, and require that sales leaders provide introductions to clients and prospects.
Redefining business strategy, target markets, value proposition, and competitive landscape is a daunting task, especially for companies that feel competitive pressure to transform or are already experiencing declining revenues. Most organizations can ill afford multiyear programs to do encompassing strategic reviews as a gating step in transformation. The world just moves too fast, and by the time a long planning exercise is done, the market will have moved significantly.
So where to start and how to simplify? Most organizations need to consider executing along three simultaneous paths shown in Figure 6-1 to help drive some conclusion.
Figure 6-1. Parallel product management activities that facilitate developing a digital strategy
One activity looks at the world through the market and customer lens, the second reviews existing products and services, and the third brainstorms and ideally pilots new products or partnerships. When an organization gathers baseline data across all three tracks, it is more ready to host a guided discussion on digital strategy. The intersection of target markets, existing products and customers, and potential new products and partnerships are the basis for forming the digital strategy.
My approach to defining the strategy is to prioritize a set of questions, reviews, and information-gathering exercises according to the track that the product leadership team should pursue. It’s important to be realistic about the number of questions and scope of research assigned to this team. Conservative organizations are more likely to want a lot more answers up front, and it’s important to expose this because it takes longer and more expense to answer them. These organizations need to reflect on these desires because decisions on strategy, transformation, and product development often require making assumptions and validating them over time through a process.
However, more aggressive organizations can fall victim to being “serial starters,” looking at and committing resources to too many opportunities, failing to get a good number of them to market, and struggling to achieve critical customer interest in many of them.
•What data can be gathered on existing customers, the products they buy, and their spending with the business over the last three years?
•Align internal and external data to any existing customer segmentations. Are they still relevant, or are there new orientations based on the impact of digital transformation in the industry? Who is likely to benefit from digital and who is likely to contract?
•Based on the data available, look to agree on “strategic” customer segments and key customers and top prospects.
•Can a set of buying personas be defined that represent the buying decision makers? Can a separate set of user personas be defined? What other stakeholder personas are needed that are parties to either buying or using the product?
•Looking at the list of target markets, define a list of product offerings that may be competitive, substitutes, or complementary.
•What industry trends, regulation, or other factors will factor into whether this market will grow or shrink over the next decade? What research should leadership review?
AUDIT EXISTING PRODUCTS
•Develop a multiyear P/L that has the underlying revenue details by customer and a high-level breakdown of the operational costs, especially variable ones. What are the attributes of larger, longer running, or growing customers versus smaller, shrinking accounts?
•Capture the rate card expressing sales channel, price points, discounting, and incentives. Is product discounting trending better or worse?
•Define buying, user, and stakeholder personas. Map existing contacts to personas and rate health of the relationship.
•What does the competitive landscape look like today and how does it compare to the existing product offering?
•Interview key users and buys. Determine their successes using the product, pain points, and opportunities. Identify whether they are using any competitive or complimentary products. Validate value proposition.
•Capture journey maps showing how prospects and customers navigate. Identify pain points and opportunities.
TEST NEW PRODUCTS & PARTNERSHIPS
•Who are you targeting with the product or service? What customer segment or segments? What are some example customers from the existing client base and some new potential customers?
•What is the core value proposition and convenience you are addressing for these customers?
•What is the product vision expressing how the solution will address the core value proposition?
•What is known about competitive offerings, price points, and size of the potential market? Forecast the first year’s revenue potential and identify the underlying assumptions.
•What are some of the inputs needed to enable the product offering such as components, capabilities, data, and processes? Of these, which ones are assets of the company, others than can easily be acquired or developed, and others that require up front R&D?
Figure 6-2. Example questions to discover target markets, audit existing products, and assess the impact of new product concepts
Figure 6-2 shows a sample of questions that you can start with and adapt to your business context. Some will be relatively straightforward to answer, while others can call for entire projects to properly research or implement. Because this strategy will evolve, it’s best to define a minimal target, other activities that can be resolved over a longer period, and others that can begin once other questions are resolved.
My strong suggestion is that this strategic planning exercise be limited to a very small group that has some history of collaborating and that brings different skills and experiences to the table. The product leadership team needs to meet frequently and likely for lengthy periods of time so that ideas can be fleshed out and documented. When documenting findings, this team must be particularly careful separating out facts from insights. Once they have a version to share with the executive team, this group will have the difficult task of bringing them up to speed on the facts, reviewing to see whether they agree with insights, and convincing them of any proposed strategy.
I like to think that 1.0 of the digital strategy should attempt to answer the following questions:
Which markets and customer segments should we target, which should we maintain, and which are least important to the future?
Of the existing products, which ones are worth growing, which should be maintained, and which ones should be shut down over a period of time?
What types of products are worth investing in? What statements can be made that provide context on the target market, nature of customer experience, and financial assumptions that can bound ideal products versus others that are less strategic or others not worth pursuing.
What are the key customer experiences that we need to enable to drive value, satisfaction, and loyalty?
What are the recommended next steps regarding strategic planning, planning on specific initiatives, and any initiatives that are in development?
When the product leadership team has sufficient facts and insights to report on these questions, then it has enough material to present a 1.0 strategy. The team next needs to decide how to present it to the executive group with the hope that that they don’t dispute facts, largely agree on insights, and are open and honest on whether they agree with your recommendations.
You can’t just show up at the executive meeting and expect this level of buy-in. The only way to get there is to review this one-on-one or in small groups so that executives have time to absorb the material and can express opinions freely. Your primary objective is to determine where everyone stands once you formally present it and believe that you have sufficient buy-in from enough executives on your recommendations. You may need to adjust your position based on learnings from these dialogs.
Even when you have presold this to all the key executives prior to any formal review, be prepared and expect the unexpected when you formally present. Executives will change their minds, attempt to add more considerations to the scope, use the data and insights that you present to push their own agendas, or even distract other members of the executive team if your plan conflicts with their objectives. It’s rare that you’ll get the positive head nods you desire even after you’ve run it by everyone.
Hopefully you can drive the dialogue to some concrete decision and follow-ups if required. If the conversation is going off agenda or if strong conflicting arguments are raised, then there’s only one answer to this situation. Get the CEO on board and make sure she knows that her role is to manage the executive team to some form of consensus.
The product leadership team should then consider how best to document the strategy and formulate a communication plan. A best practice is to start with minimal documentation and communicate with a small group of change agents that will have critical early roles in the transformation. Over time, materials can be expanded to help bring a larger audience in on the journey. It’s a delicate balance because communicating too early raises questions the team won’t be ready to answer, whereas waiting too long will create speculation and fear.
With a digital strategy 1.0 in hand, the organization can take on several parallel activities. In this section, I will concentrate on developing products and partnerships.
Let’s go back to Chapter Four where we discussed portfolio management. The art of product development is to move product ideas through the pipeline. Initially, the portfolio should have lots of ideas in the “defined” or “ideation” stage, but we want to narrow them down to the most promising ones before we get to the “planning” and “development” stages that will require more effort from internal resources and investment.
We can use our digital strategy and framework to help gauge whether a product is worthy of going to the next stage and to define the governance in each stage. To do this, the product leadership team should take on several responsibilities:
Define governance by stage.
Judge or vote on whether product ideas can move to their next stages.
Define and review constraints that limit the number of simultaneous products active in the pipeline.
Manage funding aligned to product development.
Propose and measure KPIs associated with the health of the product pipeline.
Since the portfolio should be holistic containing revenue ideas (products) and other types of initiatives (operational excellence, new capabilities, risk/compliance), the executive team should determine whether the portfolio is governed by a single steering group or there are different groups reviewing and judging initiatives depending on their initiative type. It’s certainly easier to manage the entire portfolio if the steering group is skilled in reviewing initiatives of all types and has a holistic mindset to balance what is moved forward.
Figure 6-3. Product development lifecycle through planning stages
Figure 6-3 shows the product planning process from defined, to ideation, to planning. When a product is a concept, or an idea, it should be listed and put into the “defined” stage. The founder of the idea should be listed, and the instructions to him should be to answer some questions like the ones used to define the digital strategy. Specifically, here is the initial product charter and what the founder should be able to answer when proposing a product for ideation:
Target customer—What customer segment or segments are targeted? Who are some example customers from the existing client base and some new customers?
Value proposition—What is the core value proposition and convenience being addressed for these customers?
Initial product vision—What is the product vision expressing how the solution will address the core value proposition?
Competitive landscape—What is known about competitive offerings, price points, and size of the potential market?
Revenue potential—Forecast the first year’s revenue potential, and identify the underlying assumptions.
Feasibility—What are some of the inputs needed to enable the product offering such as components, capabilities, and processes? Of these, which ones are assets of the company, others that can easily be acquired or developed, and others that require upfront R&D?
The ideation questions are designed to be relatively easy to answer, and what the product leadership team should be doing is determining its alignment to the digital strategy, validating revenue potential, and considering feasibility.
The founder should then be asked if he has his manager’s commitment to work on this idea and whether he is “signing up” to take steps to bring it to a planning. If the answer is yes, then a target date should be selected to have this completed, and the founder should be armed with materials that outline the digital strategy. From there, the product can be moved to the “ideation” stage and the founder enabled to go and capture the information requested.
The product leadership team should establish some guidelines on products that are in ideation. What’s the maximum amount of time for this stage? What resources do they get access to during this stage? What kind of help can they get from sales, marketing, finance, and technology when their products are in ideation? If you enable a large part of your organization to promote product ideas, do they need additional levels of sponsorship or product management mentorship when a product is in this stage?
They should also set expectations on the level of detail required. Product visions at this stage should be intentionally vague to enable customer, competitive, and other forms of research to better align it to market needs. A founder may be able to give only high-level information on the competitive landscape and feasibility depending on his skills and access to resources.
During ideation, the founder’s job is to follow up on any questions on the product charter, then take steps to define a backlog of what needs to be done and delivered in the planning stage. This to-do list should be in the form of a list of questions, and the goal of planning is to get answers, ask more follow-up questions, and develop a business plan for high-potential product ideas.
When drafted, the founder should prepare a readout for the product leadership team with a formal request to move the product into the planning stage. This founder should come prepared to answer the following:
What key questions need to be answered during the planning stage? These questions are typically product specific, and the founder needs an extended team of experts to answer them.
Whom does the founder want on his planning team, and what are their responsibilities?
What is the timeline for completing planning?
What other resources are needed to complete planning? This could include funding requests for market research, prototypes, and other external expertise.
What are the technical, data, and operational considerations for the product?
These last few questions force the founder to think a few steps ahead and propose what needs to happen in planning, who he wants on the team, and for how long. This information also gives the product leadership team some context to evaluate the initiative on its merits but also gives them a sense of cost and potential resource bottlenecks. Three founders on different initiatives can’t easily work with the same technologist to plan their initiatives. Initiatives that require longer planning durations, larger teams, and more resources to complete planning should have to demonstrate more revenue potential or strategic value.
What are some example planning stage questions and materials the founder should count on answering during the planning phase?
A completed product vision indicating inputs (what raw materials are needed to make the product) and outputs (what is produced and consumed by customers)
Completed research on the target market with more details on the organization’s reach into this market and what steps, if any, are needed to expand this reach
The target user personas of the product. Who are the buyers, the users, and other key players having a role in the customer journey?
An overall design of the user experience highlighting key flows, screens, transactions, events, forms, dashboards, and other interactions that make up the product.
A proposed business model, price points, and how the product will be packaged and sold
Identified competitors and alternatives and how the product’s value proposition will win over customers
Identified regulations, constraints, and other risks that need to be considered
A proposed minimally viable product (MVP) and the product roadmap beyond the MVP detailing the agile backlog for its development and proposed release plan
A technology plan identifying the architecture, computing needs, usage assumptions, and operational requirements
A data strategy identifying what data assets will be utilized, what new data needs to be procured, and what data will be collected with the product
A proposed P/L
The beginnings of a go-to market strategy for the product
The founder should account sufficient time and resources to be able to answer these questions. In addition, the product leadership team should clearly identify the list of question and any presentation formats so that the founders have a clear idea of what’s expected of them when presenting a product idea for planning.
The product leadership team should be trying to determine whether there is alignment to strategy and if the product idea is worth investing more time and energy. My recommendation is to implement a voting mechanism to capture steering members’ feedback. Scoring the initiative provides detail beyond just yes/no and gives a business value that can be compared to other initiatives in the pipeline. Since initiatives will consume resources, these scores should be transparent and are indicators to individuals, teams, and departments on prioritizing their resources. Scoring also helps to audit individual product leadership team members to ensure they balance business needs and don’t give priority only to initiatives that benefit them.
Scoring by itself may not be sufficient to move a product into planning. First, the leader of the product steering team should indicate whether it does meet the criteria to move forward. Second, any constraints such as funding, lack of availability of requested planning resources, or departmental constraints should be identified and resolved before clearing a product for planning. But once the product is moved into planning, the intention should be that, if the key assumptions on market, customer need, competitive landscape, revenue, level of investment feasibility, and regulatory considerations check out, the organization plans to invest in its development.
It’s worth noting that in my experience, every organization is culturally different in terms of how many questions need to be addressed, what level of planning is required, and what degree of assumptions or unknowns is reasonable before making a concrete investment in either planning or development. I’ve tried to present a balanced approach between what can be planned up front versus other activities that can likely occur during the development phase.
It’s good to set some guidelines. For example, for digital products that don’t have many legacy dependencies, integrations with the physical world, upfront R&D for new inventions, regulatory considerations, safety, or significant internal workflow changes, my rule of thumb is that I like three- to seven-month MVPs that require one to two months of planning. Anything longer, and you may miss the market or overinvest, and it can be shorter if you have an experienced team working with known practices and platforms.
Up to now, I’ve described a basic process to plan products. Before I review how to close out the product planning products, let’s consider what makes a product “digital” and have the potential of transforming to a digital business? These are certain things product developers should consider if they want to achieve this lofty goal. Here is a starting checklist, and you’ll notice that a good number of them relate to creating winning customer experiences:
1.How will you provide a customer experience that people love? Digital products must be easy, fast, consistent, and intuitive to use. They should provide the user conveniences and balance between activities that require user input versus activities that provide customers insights, utility, and value. This is where all that work on user personas becomes important because product developers need to validate that the experience provided enables the needs and expected use cases for each persona. How are you personalizing the experience by persona and for individual users? In what ways are you connecting emotionally to prospects and customers? How fast and “real-time” is the information that you are providing? Is it memorable that customers are likely to refer their friends or business colleagues to your product or service?
2.Great product experiences not only map experiences to personas and then personalize, they look to provide other conveniences based on context. Location and time are obvious context, but great products try to leverage other variables to provide more relevant information or more specific experiences. Inputs should include recent information the user already indicated, including the products reviewed, what online content the user reviewed, what newsletters were opened, how long and how frequently the user visited your site or store, or whether the user is at home or traveling. Context can also include other local and global conditions, such as weather, traffic conditions, what’s happening in the news, the state of financial markets, and other factors that might change customer needs or behaviors.
3.Digital customer experiences offer consistency. Customers navigating to different parts of your site or using different tools have some consistency in navigation and available tools. Search functions work across all information assets but personalize the response based on context. Performance needs to be fast and consistent.
4.Regarding the user’s identity, digital products must offer extreme conveniences registering and logging them in while being responsible about security and privacy. Are you asking for a reasonable amount of information when registering on the site? Are you taking advantage of registration and authentication mechanisms provided by social platforms? Do you have single sign-on securely implemented across all your applications? Are your forgot-password functions convenient and secure? Do you offer two-factor authentication and enforce standards on password length and complexity? Do you notify users in multiple ways that there were changes made to their personal or account information? Are you properly encrypting and securing passwords and other personal information on your servers? Are your customer service representatives trained and taking the proper steps to validate identity?
5.How will the product be designed to enable on- and offline networking? Products today can’t survive in a digital silo, and consumers expect some ubiquity and interoperability with other platforms. How is developing this network going to impact the business?
6.How will you build trust with customers, prospects, partners, the media, and with the public on social networks? Trust must be a factor in how you message, how engineers implement data security, how you implement privacy, and in your terms of service.
7.Many product developers have experience and a comfort zone in developing products for the physical world and the web, which is why many digital specialists advise them to think mobile and location-aware experiences first. Products that can offer better conveniences and insights to mobile users are more likely to provide value when users are behind a screen or in a physical environment. Are you taking advantage of mobile-specific capabilities such as notifications?
8.How are physical and digital experiences integrated? This is particularly important for retailers who have high bars to ensure that a customer can start their journey shopping in the store, complete a transaction on a mobile device, and elect to return to the store if they need to do an exchange.
9.How is pricing handled on digital interfaces? Do you offer a reasonable number of purchasing options? Do you make it convenient to compare different products or pricing options? Are you transparent with conditions that might affect the price over time?
10.Do you offer multiple payment options, and are the interfaces to input payment preferences convenient? If you store payment information, is this information secured properly in your computing environment? How easy is it to make changes to payment information, and do you proactively inform users of any expiring payment methods? Do you provide reports showing what transactions were made and make it easy to report payment issues?
11.How are you providing customer service across all your experiences? How easy is it for customers to reach out for help? How convenient is the self-service help that you are providing, and are customers successful using it? When a user reaches out to a customer service representative, how knowledgeable are they about the customer’s product usage, and are they able to resolve questions or issues quickly and with high satisfaction rates?
12.How are you leveraging the customer’s social network to provide additional capabilities, convenience, and intelligence? How are you using it to drive usage, enable repeat business, or reach new prospects? Do you make it convenient and rewarding to share information? Does your product offer digital collaboration and social function that enhances my overall utility and experience? How are you rewarding top contributors or providing incentives to users that are highly influential on social platforms?
13.How is your product leveraging the data it collects and data that should be easily accessible without violating privacy constraints or becoming creepy to the end user? Where are proprietary algorithms including those leveraging predictive analytics, machine learning, or artificial intelligence being developed that will give customers added convenience, intelligence, or insight?
14.What kind of services, benefits, and directives are you providing employees on their use of the product? Are you providing financial incentives to use and promote the product? Are there capabilities and training so that all employees can provide basic customer service tasks?
15.How are you interfacing with the ecosystem of machines, sensors, things, third-party services and the physical world to add intelligent data gathering, responsive outputs, or other conveniences? Where are you developing APIs to enable additional business services and ways to deliver new customer values?
16.Where can your product leverage automation, digital partnerships, crowdsourcing, and other methods to ensure operations are scalable, require minimal assets, and have efficient cost models?
17.What is the opportunity to enable recurring revenue sold as a subscription? What additional products and service capabilities are going to be needed over time to enhance the value proposition and to enable retaining customers and increasing fees?
18.How can your product/service evolve to a platform or develop marketplaces that enable developing additional products and services? Both platforms and marketplaces enable customers to extend how they’re using your product or service with new options made available by third parties.
19.Where are there opportunities to develop and promote the product toward social good? In addition to the contributions you are making, aligning customer involvement to donations and other places where you demonstrate social responsibilities drives a higher emotional response and satisfaction. Sometimes, even simple messaging such as encouraging users to print less can drive brand loyalty.
How are you measuring the customer experience? Do you have a full 360-degree view of all the interactions made with the customers? Can you sense issues in real time and provide services to customers struggling or others that have reported a bad experience? How strong are the analytics on customer experience to help identify who, what, and when there is evidence of great experiences and poor experiences that need improvement? Are you leveraging surveys to capture satisfaction, net promoter, and other metrics to help drive improvements?
This is not to say that every product requires all these considerations, but it’s hard to imagine digital products today without some of them. Many of these are foundational capabilities, so it’s very important for a product developer to consider the appropriate elements during product planning.
The last step of product planning, shown in Figure 6-3, is gaining whatever approvals are required to either develop a product or invest in new enhancements.
The most crucial part of gaining approvals is to get the commitments from sales and marketing to the business plan. This plan usually calls for closing a defined amount of business over a period and the sales team’s responsibilities for hitting revenue, pricing, and customer targets. The marketing team should commit to the metrics that support this growth especially if they are responsible for delivering qualified leads to the sales team.
Every product manager will tell you that getting these commitments is the hardest part of their job. Trying to get their agreement before the product is even developed is harder since the sales people have only a limited picture on what the product looks like, what it does, how it will be marketed, and how their best prospects will react to their early sales efforts. This is even more daunting for products being developed using agile methodologies where there is only a commitment to develop the MVP and where the product owner can adjust priorities.
How much of a commitment is required at this stage? Is having a business plan sufficient, or does your organization require a full sales commitment prior to approving product development? How does the organization’s need to protect against a product manager’s overly optimistic or unrealistic sales plan compare to the need to protect against a highly conservative estimate from the sales team? This can become a significant leadership challenge depending on how conservative the executive team is, the availability of funds to make product investments, and how the organization handles successes and setbacks.
Here’s my best advice on this subject. First, the objective is to get any sales commitment. If they attach a $0 to a product, then that’s clearly a red flag. Once they agree that there is some product they can sell, then that should be considered an endorsement of the product.
Second, to quantify the sales opportunity, ask a different question that will help back into it. Find out their top prospects who will have at least a moderate interest in the product. You now have a potential sales pipeline.
Next, leverage data to model this out in a very fact-based, transparent way. Use data from the CRM to determine metrics on typical time frames to prospect, develop relationships, and close business on similar products. Use third-party benchmarks if your CRM does not have this detail. Second, consider using third parties to research price points for the product. Develop a financial model that enables you to plan both an aggressive scenario (high price, high close rate, short sale cycle) versus a more conservative one.
Perform similar steps with marketing, especially on the steps to acquire and qualify leads. Marketing will have a significant role from branding to lead generation to attracting new customers and will likely be conservative in the number of qualified leads they commit to passing to sales. If the number of leads modeled is overly conservative, sales leaders will use this to negotiate a lower commitment.
Follow a similar approach by modeling lead generation. If you have similar products, determine the lead conversion ratio and back into the number of leads required for both your aggressive and conservative models. Then look for either internal or third-party benchmarks to map out time frames and costs to produce these leads.
Make sure your finance team reviews this model and plans to present both scenarios to sales and marketing leaders and later to the executive team. Make sure that you parameterize and disclose any other assumptions baked into the model.
Finally, present a conservative product development roadmap, and develop milestones that link future and ongoing investments to revenue and other marketing or sales KPIs. This will help present a lower upfront financial commitment and demonstrate to the executive team the controls you are proposing to gate additional investment.
Putting this together, you are presenting a product where the sales team agrees that there is a revenue opportunity, where you can show modeled conservative and aggressive business plans, and where investments are gated on successful revenue generation. This should take a lot of the emotions and haggling over the business plan with the hope that the executive team is ready to make a guided and rational business decision.
The executive leadership team needs to endorse what the approval steps are, what materials are required, when reviews need to happen, who needs to participate, and how investment decisions are formally documented. If this doesn’t exist in your organization, then the product leadership team should propose one and get the leadership team’s approval. Not having these guidelines can lead to a lot of ambiguity, overplanning, or underplanning when these expectations are not grounded with governing principles.
Care should be taken here to define some boundaries. You don’t want to overcomplicate the information required and steps to follow to gain approvals. The signoff should have parameters that differentiate what’s required for “small” or “low-risk” product offerings versus others that are “larger,” “higher risk,” and other parameters requiring more rigor. This is where larger organizations should consider developing standards and checklists so that smaller, low-risk offerings can go through any approvals efficiently.
Product leadership should look at this stage beyond just getting the necessary approvals. This is a critical stage to get the organizational buy-in to what is being developed and to finalize their commitment on their responsibilities bringing the product to market. Product leadership should spend time in all relevant departments to make sure all steps are captured, included in the development plan, and appropriately resourced from the applicable departments.
When presenting to the executive team, the product founders should provide a factual and emotional case on the time urgency of investing in the product. Why now? What conditions make bringing this product to market now rather than delaying? What’s likely to happen or possible if the executive team elects to delay? You certainly can present financial, competitive, regulatory, and other factors to make this case, but this is one place where an emotional, passionate case is warranted.
In my experience, risk-averse leaders who prefer comprehensive research, highly detailed product plans, more conservative investments, and perfect alignment between departments will use delay tactics rather than directly oppose a good idea. The product founders should address this directly by making a clear argument that delaying is a bad business decision and should show as much evidence demonstrating why building the product now is optimal. Translate and negotiate the final objections to things that you will follow up on, but press hard to get the approvals, even conditional ones, so that you can drive digital to the next stage.
As you begin to transition from planning to development, you should be starting to formalize your agile backlog that defines the project plan. You should also be deciding who will play the product owner and other roles in the program. These artifacts, along with an approved budget, a go-to market strategy, technology architecture, target timeline, and resource plan are some of the things that I look for before moving a product into the development phase.
The backlog should contain all the major epics and stories required to bring the product to market. In other words, this isn’t just a technology backlog. It is likely going to contain epics, stories, releases, and possibly defects covering marketing, sales, and other operational changes. By putting everything related in the program in one place, you enable every member of the team to have visibility on everything prioritized by the product owner required for a successful launch. An aligned, collaborative, cross-disciplinary team is absolutely necessary to drive digital products.
But this isn’t always easy. IT operations may be working out of an IT service manager tool. Sales may have a mandate to record all activity in the CRM, and marketing may be using spreadsheets to track their work. Are you going to take on the challenge of centralizing transformation and product development activities?
It’s your call. You can manage everything centrally but without all the active participants collaborating in your backlog tool. This will likely require you to have a project manager in addition to the product owner to keep track of activities performed by people who can’t or won’t collaborate in a central tool. If you’re up to the challenge, getting everyone on the project looking at one backlog, one news feed, and one set of reports and updating their activities has significant advantages.
Agile development was covered in Chapter Two, but let’s review some concepts from the perspective of a product owner. There are many books and articles about product ownership, so I am going to focus only on some important concepts.
Product owners start a development project with a vision and a list of everything that they want the product to deliver. In many cases, the vision, strategic requirements, and primary functional requirements have been gathered by soliciting information from customers, prospects, and key salespeople. It also likely includes requirements driven by competitive needs, compliance, operational, technology, and security requirements. In some cases, the product owner has made commitments to have certain capabilities available in the product, sometimes to enable sales to an early buyer, others because of minimal compliance requirements, and others because the product owner made promises to internal stakeholders to get their approval.
Product owners also made commitments to deliver a product on a timeline, budget, a defined set of resources, and an agreed-upon technology architecture. In effect, these are some of the constraints the product owner has to manage to in order deliver the product.
So, given the variables of scope, timeline, budget, and quality, how is the product owner going to manage tradeoffs, conflicts, risks that materialize, and new needs that are learned or discovered during the development phase.
A fundamental principle of agile practices is that, given these multiple interdependent constraints, agile practitioners advise on managing to timeline and budget first, quality a very close second, and scope third.
Now it is counterintuitive to many product owners to accept and manage to timeline first and manage to scope last, given all the work they’ve done learning customer needs, convincing stakeholders, communicating vision, and even documenting some fundamental requirements. Why is scope last?
There are a couple of tactical and strategic answers. First, agile provides a framework for the product owner to see iterative improvements. You might see a skeleton of a product in sprint one and more capabilities in sprint two. The product owner may then look to go “off plan” and adjust scope and priorities because of something that was learned through a demo or from engaging customers during the development period. You can’t expect a development team to hit the original scope when the product owner has a license and authority to make some degree of scope changes.
Second, estimations are inherently just that. They are best-effort estimates based on what the development team knows, what they assume, and what they understand behind the technical implementation. What happens when the estimate is off and something is going to take longer to implement than forecasted? At times, you can make up the time elsewhere or ask the team to work harder. But in general, if something is taking longer, the product owner should make decisions on whether to maintain scope and extend the timeline or keep to the timeline and modify the scope. In most situations, agile practitioners will advise to compromise on scope rather than extend the timeline.
The strategic rationale is that you almost always have a second chance to come to bat if you miss on scope. You can have a customer lined up ready to buy that will buy anyway even if the scope isn’t exactly what was promised. In this situation, the product owner has made the right decision on deferring scope because there is little business impact in missing the feature. Maybe you learn that the feature isn’t that important anyway. If it is and the customer is upset, as a product owner, you can offer to discount the purchase until the missing feature is ready. Worst case, you can attempt to close the sale but only fulfill it once the feature is available.
But miss a deadline, and the product owner now has some harder issues to overcome. First, there’s a loss of credibility with stakeholders and potential customers that often requires significant energy from the product owner to overcome. Second, when the product owner misses on a delivery date, it often implies a budget impact. Third, most product plans use the delivery milestone to drive other business activities such as marketing, training, and sales activities, so missing a date can have significant implications working with business teams and schedules. Finally, the best product owners will align delivery dates with other business events that enable them to get a marketing boost or a more efficient internal rollout. Maybe there’s an industry event that will enable a large number of prospects to learn about the product. Maybe there is a manufacturing schedule and penalties for delays. Maybe the sales team is coming in for training and is the best opportunity to get them ready to learn and sell the product.
Missing on quality is a close second because it’s harder to define minimal, acceptable, and superior quality. A big part of quality is the underlying user experience, and if it isn’t easy and convenient to do the most important things, then buyers are more likely to consider alternatives. In many cases, it’s better to deliver a superb experience on a few things rather than a clunky one on many things.
There are other forms of product quality, including stability, performance, security, and reliability that need some form of minimal acceptable criteria. But even these criteria have some variability depending on how their acceptance criteria are expressed.
You need a product owner to have guiding principles that are aligned with digital product delivery.
Define an achievable minimally viable product defining strategic capabilities and quality criteria required to bring the product to market. The key word here is “minimal,” and the product owner should challenge whether she can address a sufficient part of her business plan with every additional capability or quality criteria introduced in the MVP. In my experience, the single biggest mistake a product owner does is either not expressing the MVP or oversubscribing it with too many capabilities, quality criteria, or other requirements.
Let me illustrate this by example. Let’s say you are targeting to sell 12 customers over the first year of a new product and expect a ramp-up with only one customer in the first quarter. Is the MVP what is needed for 12 customers, one customer, or something in between?
The answer should be what you think is needed for one customer, but to do this properly, the product owner should plan and budget a full-year agile program. First, the product will need funding for ongoing development so that capabilities can be added and improved on to hit the full sales target. Second, the product owner needs sales to have several active prospects in the first quarter to increase the likelihood that one will close.
Set reasonable expectations with customers and stakeholders on the scope of product delivery. Product owners should consider themselves as members and leaders of the delivery team. Most of the organization will not understand the concept of managing to an MVP or leveraging market research and agile practices to enhance products over time. Many won’t care about the complexities of product development, adhering to security or compliance requirements and just want to know that a product that customers want to buy will be done on time and budget. Smart product owners set reasonable expectations up front, knowing that they need flexibility to manage unknowns and changes.
Partner with your leads, and follow a methodology for prioritizing. Product owners should use their vision to make sure that the whole team has a shared understanding of what they are trying to build, for whom, why it will provide value, and what they will need to win. That’s the big picture the team needs to understand, but after that, they should be more focused on what they are doing today, this sprint, and this release. To make teams productive, the product owner should be working with their leads to force-rank everything that goes into the product development backlog. Product owners can reorder, add, or delete from the ranking based on the governance agreed on, but the ranking needs to be explicit to drive alignment and productivity. Most people can’t look at ten number one priorities and implement solutions that address everything.
There are a couple of other ways product owners can help your leads. First, they can learn agile and other technical lingo, which fosters better teamwork, more efficient collaboration, and a respect that helps everyone perform better. Second, they can thank the team frequently because today’s triumph will be forgotten tomorrow when a new issue needs resolution. Finally, they should listen and value the team’s opinions and ideas. Product owners should be careful not to overly fall in love with their own solutions and must engage the team to provide ideas, feedback, and innovative ways to address challenges in smart efficient ways. Lastly, leads should be telling the product owner about operational needs, technology standards, defects, and technical debt that need to be considered for prioritization.
Own communications, and communicate frequently because things move fast in an agile process. When are demos, what priorities have been lowered, what new considerations have been added to the scope, how can others recognize the team for their accomplishments, where is help needed, and what material risks are being mitigated?
One word of caution is that communication requires some art and science. You don’t want to communicate every hit or miss because the swings may be hard for stakeholders to comprehend. Sharing too much detail might overwhelm colleagues, but being too generic or lacking any drive may risk losing the audience over time.
For this reason, product owners need to have a plan for engaging and communicating with stakeholders. The primary goal is to set reasonable expectations up front, then to communicate status frequently to ensure stakeholders are not surprised later in the development process.
Get into the weeds, and expect to spend a lot of time with the team. The agile practice requires a strong commitment from product owners to help set priorities, communicate requirements, and listen to the team’s ideas and needs. Gone are the days of giving the team all the requirements up front and asking them to manage and deliver it. Product owners should be attending release planning, sprint planning, brainstorms, and demos at a minimum, and many agile teams want the product owner at daily standups. My target is that the product owner should be spending at least 40% of their time working with their teams.
Product owners need to spend considerable amount of time reviewing with the team customer needs and what drives value. They should share the overall product vision but also break this down to the vision of the release and the vision of the sprint. This helps team members understand goals and objectives in the context of the stories that they are working on.
From there, product owners need to express what they need in the form of problems and ask the team for solutions. “What’s the best login experience that we can implement in one sprint that allows very busy users to leverage their LinkedIn or Twitter accounts?” “How can we best enable users to search by geography when some users want to look at large, multistate regions and others want to narrow down to cities, counties, or even zip codes?” These problem statements should be enhanced with why it is important to users or how a solution may impact the value they get from the solution.
Nonetheless, you can see how the product owner is expressing what she wants but avoids the specifics of how to implement it. She should be giving the team the responsibility of identifying one or more solutions and expressing any advantages or disadvantages in them.
So how can the product owner influence solutions? Work with the team is to be as expressive as possible with the acceptance criteria related to solutions and agile stories. For example, “It must allow registering users from their social media accounts without keying in any new information.” If the team doesn’t have a solution, the product owner should consider prioritizing one for a brainstorming session or look to schedule spikes to help work out technical approaches.
Product owners should avoid the urge to add/change stories inside the sprint, which can be very disruptive to the team. Agile teams work in rhythms. At the beginning of the sprint, they are in thinking/planning mode; during the sprint, they are focused on fulfilling the story; and at the end, they are closing out defects. Changes midstream create an imbalance and can be particularly disruptive if there are multiple teams or if the teams are distributed geographically. Now most teams are flexible (being agile) and will accept some changes/additions, but this should be managed as an exception, not the norm.
Product owners should set the agenda for the demo and look to have key stakeholders attend. They should capture feedback but avoid letting the demo turn into a brainstorming session for any issues raised. They should work with the team to accept stories that are done and be specific on where the team fell short of expectations.
But the most important mistake I see in product owners is when they don’t thank their teams. One release leads to another, and when one sprint ends another begins, so it’s easy to lose sight of accomplishments. Team members don’t forget.
Product owners need to be exceptional collaborators and know where their responsibilities end. In most organizations, team members do not report directly to the product owner, and how the team allocates work should be left to the team. In addition, most product owners don’t have the skills to measure the productivity, quality, or overall skills of team members. Stepping into the realm of managing the team is a critical mistake product owners make, and it can create significant negativity and disruption when this happens.
Instead, product owners must manage through influence and bringing the right people together to collaborate on priority opportunities and solutions. In some cases, product owners should drive multiple stakeholders to consensus; other times they should drive teams toward solutions that meet multiple needs and constraints. Driving consensus, pushing team velocity, and nurturing optimal customer solutions can’t be done consistently by demanding product owners who don’t listen and collaborate.
Product owners should present data before analysis or opinion. Everyone has opinions on what to invest in, what to prioritize, what customers want, and what solutions are optimal. Product owners in businesses should help drive consensus and coalesce opinions to investments that grow customers, increase revenue, and drive customer satisfaction. A product owner without data to back their analysis, ideas, and solutions is just another stakeholder with an opinion.
What data should product owners pursue? They need to be looking at product usage data to understand how customers are interacting with them. They need to interview existing clients to see what is and what is not working for them. They need to couple this with information from prospects and from customers no longer using the product to determine gaps and points of dissatisfaction. They should be using market research firms to gather more data about the competition. They need to be looking at financial data on how the product is performing and review its profitability, along with marketing data on the successes, failures, and learnings on attracting prospects.
Product owners need to become product evangelists. They should be out in the market speaking at conferences and events. They must visit key clients, see how they are using products and services, and learn about their opportunities and issues. Most important is that product owners need to be an expert in how the product works and its configuration capabilities. They should be versed in running slick demos on the spur of the moment and tailor them to the audience.
They should go on sales calls to different types of customers and learn what’s working and not working in the sales process. They should also be well versed in competitive offerings and specify to sales members how to respond to questions about things the product doesn’t do today.
In the process, product owners should update their vision with a roadmap. The roadmap helps employees understand the future direction of the product that includes a statement of priority and a forecast on timing. The best product owners will engage their teams to help develop the priorities and any forecasts tied to the roadmap.
Product owners need to balance capability with operational and compliance-driven requirements. Product owners that only drive the development of new features, capabilities, and configuration options are doing a disservice to their customers and organizations by underinvesting in the underlying operations, security, performance, scalability, and analytics of the product. That’s one difference between getting an MVP out, to growing the customer base, to getting the product to become a stable, reliable platform.
Product owners should also be listening to their technical leads, architects, and delivery managers on getting technical debt addressed. Technical debt is a list of improvements in the underlying software that the technical team recommends addressing. In some cases, these are shortcuts they’ve taken to ensure that they can hit a delivery date; other times, their implementation needs an upgrade based on new learnings, operational considerations, and the availability of new technical capabilities. Regardless of cause, products that address technical debt systematically are less likely to have operational issues or degrade into legacy.
Product owners should also be reviewing the overall quality of the product. Defects need to be addressed. Data quality issues should have automated solutions or workflows addressing them. Teams must understand the impact of quality issues on customer experience.
Product owners need to identify partners and join the ecosystem. Today’s digital products cannot survive in isolation, and organizations developing new products are unlikely to succeed over the long term without successful partnerships. Product owners should consider doing SWOT analysis (strengths, weaknesses, opportunities, and threats) to help set some guiding principles on where to consider partnerships and where collaborating with third-party services provides strategic advantage.
Product owners need to leverage their technologists to look beyond business partnerships. Where can third-party APIs provide capabilities, and where can developing them enable revenue opportunities? What third-party services provide additional data, algorithms, analytics, machine learning, artificial intelligence, and other capabilities that increase the intelligence, insights, and conveniences in the products and services being offered? Are there new attractive distribution channels in promoting applications in third-party app stores or even evolving the product into a platform of its own?
Some of the more advanced capabilities help organizations evolve from digital channels, to products, to evolving businesses.
The last major role for product management is in developing the go-to market plan and overseeing its execution for the product. This is an entire discipline that lies in the intersection of marketing, sales, and general management. The exact role the product marketer needs to take on varies considerably by organization structure, the availability of specialized talent, and the exact needs of the product.
What are some elements of this strategy and plan that are critical for organizations building digital products as part of a transformation?
Branding of digital products and services is important if the products are target new markets or help position the business in a new digital context.
Pricing, bundling, unbundling, repackaging, and discounting are all important considerations especially if the product is bought directly by end consumers or if the product is an extension of an existing “analog” product.
Marketing plans need to factor how to introduce the offering especially if there are new or evolving brands in scope. They should consider digital marketing capabilities to promote the brand, bring in leads, and nurture leads to be primed for sales activity.
Sales process—Product owners should work collaboratively with marketing and sales leaders on an overall sales process. Who is selling the product between existing and new field reps, inside sales reps, and direct? What are their targets? What activities should be performed from first interaction to close? What sales materials should be used, and what guidelines are you providing reps on whether and where they should tailor the presentation?
Sales relationship and pipeline management—Many organizations that have long standing products and services are less likely to have structured sales governance, pipeline management, forecasting, and measurement practices. Worse, many organizations must transform sales teams that were successful selling analog products that “sold themselves” with few competitors.
Sales of digital products can be super simple when they are direct to buyer and offer freemium or try/buy options. Digital products being sold by inside reps or in the field can be more complex versus their analog predecessors requiring salespeople to develop new relationships, understand buying personas, capture disparate customer needs, and distill all the information in an orchestrated sales process that leads to a closed/won, captured in a CRM.
In addition, sales leaders need more advanced analytics from their CRM to understand the overall health of the pipeline, to manage salespeople effectively, and to make macro and micro planning decisions on territories and assignments. They need to provide constructive feedback to the rest of the organization on what is or isn’t working well enough in the product, in marketing’s leads, and in the sales process.
Working with distribution partners—Product managers need to look at opportunities to enable resellers, product integrations, and other business development opportunities. While some of these may be traditional business development opportunities, product owners need to consider other digital partners. If you’re selling a product to a sales or marketing team, then you’ll want to consider developing a CRM application sold through a vendor’s app store. If you’re developing a data product, then you’ll want to develop APIs and partner with developers to conceive new applications.
Legal, financial, and compliance considerations—Product managers need to work with their legal and financial teams on everything from developing contracts, identifying terms of service, and ensuring that compliance considerations are identified and managed. They should be working with finance teams on developing product codes, reviewing order-to-cash practices for any new requirements, and identifying any new considerations for invoicing and charging customers. This is not a onetime effort because adding new customers will require deciding what terms can’t be amended, others that can change based on customer need, and others that need to be considered for global changes made on a periodic basis.
Establishing credibility and trust—Lastly, product managers must bring some rational thinking about what the business should do more of and should not do in selling, marketing, or developing the product that influences the sentiment, credibility, and trust that consumers have with the business and the product’s brand. In this regard, the product manager must partner with privacy officers, security officers, compliance, and marketers to determine appropriate guidelines. Product owners have to recognize their level of authority in these discussions as many security, privacy, and legal guidelines are enterprise-wide and not negotiable for a specific product.
As noted at the start of the chapter, establishing product management practices and enabling them within the structure of the organization can be a difficult transformation. Leaders aren’t always aligned on the roles and priorities of the product team and can become defensive when the team drives changes against established practices. Furthermore, product management needs commitment from resources in sales, marketing, technology, and other departments, so leaders have to be willing to allocate their resources to these efforts. When a product isn’t selling as expected, leaders should listen to product managers on adjustments or even pivots to strategy. However, when products have conflicting priorities from customers and sales, leaders have to respect the prioritization decisions empowered to the product team and accept answers of “later” or “no” to some of their needs.
The pressures and tensions can be very demanding on the product team. I’ve seen talented product managers crack under the pressure. Others have been in the trenches so many times that they may revert to demanding, confrontational behaviors because of the ongoing pushback they receive.
Product managers fall into traps that can make their hard jobs even harder.
The first trap is when they do a good job of listening to customers and stakeholders but then try to give everyone what they want. Product owners in this camp fail to recognize that they are working with finite budget, time, and skill and that their role is to digest the input, then communicate a set of realistic priorities, strategies, and requirements. These product owners need to communicate the rationale behind these decisions and accept the fact that they aren’t going to make every stakeholder equally happy. Their job isn’t to make people happy but to make decisions that drive customer adoption and growth.
The second trap is when the product owners fall in love with their vision to the extent that they fail to listen to stakeholders, including the technologists that they need to partner with on solutions. Product owners need to constantly reshape their vision and priorities based on feedback. Second, product owners need to share and communicate their vision repetitively and gain buy-in over time; otherwise, stakeholders will communicate their objectives, often loudly and forcibly and probably late in the development process when changes or pivots are costlier. Lastly, product owners need to shape their vision at least partially based on the organization’s capabilities, so they need to be presenting opportunities to their team and learning feasible solutions from their team.
A third trap is when they become overly demanding of their engineering teams or treat development estimates like a contract. Agile estimation is a key tool to form a dialogue about solutions, to drive a discussion on MVP, and to help teams plan releases. Agile product owners should use estimation as feedback to make decisions, but some fall into the trap of using estimates to manage their teams to fixed timeline, fixed-scope releases. Sometimes it works, but when estimates are done early in the process or performed by less mature teams, they will have degrees of inaccuracies. Agile product owners that “box in” their teams to fixed schedules and deliverables will lose their ability to adjust priorities, or, worse, they may degrade the culture that drives both execution and innovation.
The fourth trap is when product managers underestimate the power of using data in driving decisions. When product owners present data first, it becomes a lot easier for them to drive priorities and decisions. Why are we working on these features for the next release? Because 30% of surveyed users requested them. Why aren’t we discounting the product more aggressively? Because we’re still 10% less expensive than our competitors, and 20% of prospects that say no come back within 60 days and say yes. Responding with facts backed by data often diffuses passion-driven challenges and is the best weapon product managers can master to gain alignment across multiple responsibilities.
The final trap is when product managers don’t recognize that they must master multiple personas. Most of the time, they have to be highly collaborative and be able to manage everyone’s ideas and priorities. Later, they may need to be humble to get help understanding a technical concept or need a department’s help getting specific tasks completed. They have to be mentoring, especially with senior executives to help them understand strategy, customer needs, and product decisions. Lastly, they need to be demanding drivers to ensure that deadlines are met and key customer needs are fulfilled.
The trap is when the product owner fails to separate out these personas and applies the wrong temperament to the wrong situation. Worse is when they get locked into one or two personas. A demanding product owner will come across as a bully and will fail to inspire a team to greatness. An overly accommodating product owner will get run over by leaders who are more driven by their next paycheck or have very little incentive to enable a longer-term strategy.
Digital leaders should recognize that the product management function is critical to driving digital transformation. If you’re a CIO chartered with transformation or a CDO brought in to enable one, the responsibilities outlined in this chapter need to be at the top of your priorities once you have a baseline agile practice established.
How you go about this in your organization largely depends on the existing culture, organizational structure, how individual leaders view their responsibilities, and to what extent product management practices already exist.
As a digital leader, establishing a product management function may be the most difficult undertaking compared to agile, portfolio management, or becoming data driven. Developing products and services is critical to all organizations and affects all departments, so it’s hard to imagine leading this without facing confrontation, obstacles, passive aggressive behaviors, and other reactions.
You’ll need to elicit the executive leadership team to sponsor and support the product management function. They need to be explicit about where organizational boundaries lie and to provide guidance on instituting product team members into the organizational model. You’ll have to decide how fast to push the organization and whether you are driving too fast or too hard.
And since many leaders don’t fully appreciate how fast digital can disrupt your business and industry, you’re going to need to educate them on the need to move smarter and faster.
