Accelerating the product agenda: a blueprint for developing a pragmatic product roadmap.
So you have landed your CTO/CPO dream job and launched yourself into your new organization with enthusiasm. Excellent!
A day or two later, having learned where the coffee machine is, but not a lot more, your new boss reaches out to you to ask for your views on the firm’s products and your plans for product development. A reasonable enough request, but one that causes almost everyone some anxiety early in their new role.
Where to start? Putting together a plan with imperfect information could leave you well off the mark, but not delivering some insight early can also erode your credibility and your ability to influence the product development agenda.
Having been in this situation more than a few times, I have developed an approach that has served me well across a number of different industries. I come from a strong technology, consulting and software product background. Hopefully some of my general approach will translate to other product categories and; for those of you who have also found yourselves in this situation; I would love to hear your views on what worked for you.
At this point I should also clarify what I mean by “product”. I define a product as any combination of technologies, service offerings or platforms that will be packaged together as a customer offering. Even a can of beans has an ecosystem of components such as brand, ingredients, recipes, food standards, consumer support and social media advice - all of which makes up the product experience.
I will also use the term “product agenda”. What I am referring to here is the process of securing sufficient resources – whether time, dollars, people – to build great products that meet a customer need and can deliver value for stakeholders (e.g. for commercial organizations this is either directly via EBITDA, or indirectly via capital appreciation). Yes there are time, strategy and brand considerations that this definition doesn’t adequately capture, but ultimately the aim is to build something that satisfies a customer’s need (even if that is just a beautiful experience), and creates value for owners.
The first 30 days: Finding your way through the maze
The first 30 days in a product leadership role is a bit like making your way through a maze. You know you’re in a maze; you know you will ultimately find the exit; but you have no idea how far you will need to travel to get there and what twists and turns are ahead of you. The product maze is particularly influenced by the organization’s strategy, markets, capabilities and, most importantly, risk profile to drive growth or change.
Hopefully I would already have a good sense of these factors, having undertaken some solid research during the hiring process. I try to talk to a selection of suppliers, customers and ex-employees over this time. This information, coupled with the insight gleaned through the interviewing process, helps me understand why my new business has formulated its particular mix of propositions / solutions in the market. It also gives me an appreciation of the general organizational dynamic influencing the current product strategy.
From here, I need to understand the products’ market opportunity, customer demand, current products’ competitive and technical opportunities, and any new technological enablers / trends that impact on the products. I immediately ask the team for this information. How long it takes for them to provide the information, what level of rigor exists and how views are articulated and substantiated will be very informative one way or another.
During this assessment phase I am also looking at the maturity and alignment of the activation, customer experience and core value chain activities within the business. I have often discovered on joining a new organization that the business has an incomplete understanding of how each product is sold, fulfilled, supported and priced. Usually this is because:
a) the firm has undergone a lot of change and some institutional knowledge has been lost or;
b) the business is very siloed in its processes and/or;
c) the need for the process wasn’t recognized.
To find out which of these situations is the basis for the incomplete understanding, I find it is useful to ask myself:
How well does the business understand these processes (in detail and as an abstraction)? This is a particularly important consideration when assessing the leadership of an organization.
How much demand is being placed on my product / product development resources from these processes? For example, why are Product Managers / Designers being pulled into every customer sales call? Or why are Product Managers / Designers never attending customer sales calls?
Is there enough capacity / skill / energy being applied in the right places to support these current requirements, and how will the total capacity currently support the execution of any new product development initiatives?
What numbers I have inherited? Get a sense of where the revenue and margin is tracking, and the current costs (direct and indirect). How quickly does the team receive information on a product’s financial performance? Slow reporting cycles (of any type) are generally good indicators of poor information flowing though the value chain, and could indicate poor understanding of value chain execution.
The takeaway from this is that when you start a new role, it is essential to quickly identify any technical and resource constraints in core value chain activities, as you need to free up capacity to deliver a product plan. If your people are spending most of their time dealing with ad hoc demands from the business to support the core value chain, they won’t be able to focus on delivering a product roadmap. Conversely, if you have no one supporting these processes, effectively launching new products could be problematic.
At a tactical level, you may explicitly strengthen oversight of the current process by assigning a dedicated resource to it. This resource should be aimed at improving standardization of product propositions, pricing support, and customer issue resolution. The resource generally needs to be senior because in this situation I am aiming to change inefficient practices. It usually requires some horsepower to shift the inertia of established processes inside organizations. They should also be helping to up skill others in the business who should be in charge of these processes, and supporting them to build necessary collateral and training materials, etc.
Focusing on the endgame: how can I add value?
At this point I also tend to ask myself some basic questions to ensure I am focused on the value I can add to the new job. These questions are useful not only for developing the plan, but also for framing my approach to my first 100 days in a CTO / CPO role.
I ask myself how do I:
Drive improvement in product leadership?
Ensure the product is fit for purpose for its customers?
Optimize the product design and development team to support the broader organizational strategy?
Get a read on the sort of shape the team is in? Is there anything I need to do early on to improve the moral/cohesion of the team?
These are pretty straightforward questions. However, I have found that unless I get clarity around these issues upfront, operational pressures can, and will, mean opportunities for base lining the new product agenda have been lost.
Days 31-60: The rights resources in the right places
The next piece of the puzzle is to make sure I have the right resources in place to create and execute the product roadmap. I fundamentally believe the organization’s product managers MUST be the absolute domain experts in their category. They must not only understand their products extremely well, but they must also know the details of the processes feeding and supporting those products, so they can continuously improve them. For technically oriented products, this would extend to being able to direct engineers, researchers and development teams from a requirements perspective. If not the product management will simply not have the intellectual or institutional credibility to be able to do their job. This is a very high bar, but absolutely necessary, in my experience. Most CTO’s / CPO’s work out pretty quickly which of their folks are up to this.
I firmly believe that most teams know what needs to be done. Whether or not they are willing and able to do it varies significantly. For me, the worst situation is inheriting a team that has suffered from a lack of leadership and therefore is exhibiting some dysfunctional behaviors. They have lost their mojo and tend to stop fighting the good fight, settling into whatever level of effort allows them to meet the minimum requirements of the job. In whatever scenario you find yourself getting a read on the state and capability of the team is massively important. Some of the basic questions I ask myself are:
Who in the team really has a handle on the customer and channel requirements? More often than not these folks are the ones who have been fighting for good product disciplines but whose voices have been lost in the crowd.
Find out what projects have been successful from the perspective of each of the team members –it will give you a quick read on what they like to do and the balance of the teams demonstrated skills.
What do your internal stakeholders think about the teams and individuals performance? Is this material and does this map with the evidence you see?
Is there anyone clearly over or under worked? Why?
Do I have any data nerds who can be relied on the find good reliable sources of data for the team? I love these guys and gals because they can be real cheerleaders for good practice because they are likely see the results of bad practice.
Anyone asleep at the desk? If you give them a kick will they wake up?
Anyone demonstrating a low level of commitment or comprehension? Why?
Anyone clearly not able to perform?
At this point I am also making an assessment of the impact of the resourcing requirements for operations, in-flight projects and the product plan process. How much capacity do I think I might need for the operational and project work that we know about today? How would that change based on the roadmap activities required and the skill profile of the existing team? Where can I source the missing skills? How long would this take? How would I organize the team?
On this point I would argue in a product team structure should be aligned to the speed of change that needs to occur in the market/product strategy. The faster one needs to go the more likely it is you will need to separate resources pools between operations and project work (e.g. creating a new product). In a more mature category the product development may well be supported with normal operational resourcing levels. This means as a CTO/CPO you will be managing different modes of operation in different categories and the mix of modes will change from time to time. This will require your organization to be fluid in its structure and more about the skills mix required than about formalized roles. This is one of the components of agile delivery that does challenge traditional organization structures and can challenge hierarchically minded product teams. I have some further views on how to operationalize this approach that I may elaborate on in the future.
Days 61-100: Building the product roadmap
The process I use for building the product roadmap has been relatively consistent, irrespective of the industry. The basic steps are:
Market Sensing
Assign resources to build a repeatable process for the analysis of:
Activation activities:
campaign results
sales pipeline
web metrics, etc.
research
customer feedback
design considerations (A/B testing, etc.)
quality measures / returns / complaints
competitor activity
pricing / financial analysis and usage data
This will lock down where the feature demand is growing / changing in each category / product segment.
Sort out the sources of capital available for new product development. Different organizations have different policies about how and where new product development (NPD) capital can be sourced and deployed. This is important because it will significantly influence your freedom to act and ultimately the markets you will sell to.
Strategy and Design
Build a plan to recruit a community of interest to source new product input – key influencers, customers, market and technical experts. This is effectively a product advisory board that has credibility with your internal stakeholders and can build your capability as a product team.
Engage internal and external technical architects, business owners and product stakeholders to ensure you are executing the optimal technical designs for your product and market. These may or may not include members of your product advisory group.
Build a feature / defect backlog – empower the business to prioritize and interact with the backlog. Encourage debate. There are a number of simple online tools, which can assist in this process (have a look at Product Plan and Aha for starters). Start simply, quickly and engage people. I will be writing separately about this process in a future post.
Identify and target internal and customer / partner champions for strategic roadmap features. This includes building product roadmap stories in the areas of strategic value to help the activation process. If nothing else, it may open co-funding opportunities for core product plan feature sets. Constantly test your stories with customers and the channels.
Talk to customers personally. Communicate heavily about this engagement to get alternative internal perspectives on this customer feedback.
Feature Alignment. In terms of each product, look at larger customer segments and/or regional groupings of features. Work hard to create an alignment between the needs of different regions/segments. My key learning from really working at this is that it:
simplifies prioritization by de-emphasizing partisan segment or territory interests; and
reduces the overall NPD and product release costs; and
creates greater marketing and technical re-use of collateral, intellectual property and consequently less technical debt.
However for this to work it does need your team to be very explicit about the trade-offs of standardizing features with their stakeholders. It also creates some philosophical angst with the Agile purists because iterations and refactoring (i.e. changing existing features or creating specific new features rather than waiting and delivering a more comprehensively fully featured solution) is a core part of the methodology and the standardisation of features is often believed to be to constrictive. There is a balance to be struck here and one should always seek to avoid some of the costs of spot feature development. Depending on the maturity of one’s organization, this discipline can sometimes be difficult to implement.
Team and Systems
Focus on team make-up and development (NPD) requirements. Identify and isolate the areas of under-performance and make these part of the team’s continuous improvement discussion. Remove disruptive or poorly performing team members quickly as it will take time to replace key skills and knowledge.
Compartmentalize NPD conversations. Everyone is a NPD expert and so there will always be plenty of input. One of the joys of the job! I have found the NPD dialogue needs to be consciously structured and iterative to be effective. There are five key conversations which need to take place in a Product Roadmap process. These conversations overlap but are different and should be conducted discretely (more on this later). The five conversations are:
Ideation – the “what and why”. In some cases it might also be the “if / if not” conversation. This is about strategy, differentiation and market / product fit, which also means we are talking revenue, market share and strategic value.
Design – what are the specific capabilities and experiences we want to deliver to our customers / consumers? How do we measure these experiences? What does “good” look like? What are the price / benefit dimensions and where do we monetize in the customer journey?
Prioritization – the relative ROI discussion. This conversation should revolve around prioritization relative to the other features / experiences we have in our backlog. At this stage the discussion is not about what should and shouldn’t be done. It is also not about when it will be delivered (which is scheduling below). This discussion is just about which order things ideally need to occur.
Funding – who is going to pay, and how fast could we go given our funding levels? This is a biggie as alignment around funding sources, the process of funding allocation and governance structure is essential. This is something I will specifically explore in an upcoming post as I believe it is a major enabler to the success of NPD in any firm, particularly those implementing XP, Pragmatic or Agile delivery programmes.
Scheduling and activation– when can we deliver? How do we want the customer to become aware of and consume our product? When can we resource the support requirements? Do we have capacity? If something slips its delivery date, what impact does it have on each of the other Product Roadmap conversations (e.g. Ideation: If we can’t deliver when we said is it still something we should still do? What impact does this delay have on other customer experiences we wanted to roll out? etc.).
These conversations are best held discreetly as they can have separate stakeholders, and regardless it is good discipline to recognize that you have different objectives for each discussion. I have experienced situations where everyone is in every discussion and we have not clearly separated the agenda, which is not a good way to build great products or get them delivered.
Build and maintain your roadmap in a system (like Asana, Product Plan, Aha, etc.) not as a document/slide deck. This poses some challenges in communicating up, but means that the folks doing the work are working in a living, responsive, prioritized work environment and feature set.
Implement a system of traceability for all feature and defect requests for continuous improvement and tracking. Work hard to maintain feedback with a requestor, even when the feature/defect may not be delivered for some months. Remember some of these requests will come from customers as enhancements or via your support channels – closing the loop scores big goodwill points. Report statistics on all requests regularly. For example ten (10) oldest defect requests, feature/defect requests received this week, etc.
Continuous Improvement
Make sure you are always aware of the cost of delivering a current feature set and be clear on where you are going to get the return. If you can’t convince yourself, challenge yourself as to why you would proceed with a specific feature – even if there is some demand. Switching off low ROI features and migrating customers to new value creating platforms is a large part of a product leaders job in a digital environment.
Balance innovation capacity with the need to minimize technical debt. Technical debt, such as old code, poor user experiences, old technologies, etc., is a killer for good products because it slows your innovation velocity, increases complexity and impairs product performance over time. Investment in the capacity to reduce technical debt needs to be a continual consideration for the Product Roadmap. Keeping on top of this is a product leadership issue and not something only the techies should care about. Where a decision to accelerate a feature or product is made that introduces technical debt as a consequence, that debt should be estimated and explicitly budgeted into the cost to deliver. This includes the migration effort for obsolete platforms, pricing and product features.
Never lose sight of technical excellence, superb user experiences and quality. Resist the temptation to increase feature velocity at the cost of good quality execution throughout the process.
This process is likely to consume most of your first 100 days, particularly in a corporate environment. In some businesses, such as with start-ups, it can be achieved much faster, as start-ups are focused on product to market fit, proving revenue and implementing the basic customer journey. Having said this, a start-up will not always have all the resources or market awareness to be able to address the full set of product requirements, so there is invariably a lot of rework and re-engineering involved. Whatever situation you find yourself in, the product leadership role is one of the most challenging and rewarding in the business. Have fun in your first 100 days!
I would love your feedback, questions and thoughts. I am interested in building relationships with others interested in issues of Product/Technology leadership. Feel free to contact me on: mike.hendry@neolokus.com.
acknowledgement : Thanks to Karl Laird (www.cin7.com) and Alison Brook (www.bayroadmedia.com) for their input and critique.
© 2016 Neolokus.com
