How to establish an initial product roadmap in 10 steps | by Paul Burke | Nov, 2021


Savvy end users have more agency than ever before in the selection of software and services. They now have the expectation that the B2B and B2B2C companies that they interact with will deliver consumer-grade digital solutions with user experiences that are more attractive, intuitive, powerful, and affordable. And if they don’t get them they will vote with their feet and find a company who will deliver on that expectation. This shift, often described as consumerization, has led companies of all sizes and in all categories to shift their organizations towards product-led practices.

Being product-led for an organization means that the company is guided by the potential of products and product teams through a planned, rolling, multi-year roadmap. Through this generally accepted enterprise roadmap, the company then plans for these potential products and using collaborative methodologies like Agile HCD, Design+Sell/Build and Milestone-Driven Innovation to validate solutions from three critical perspectives: desirability, viability, feasibility.

Desirability (end user centered)

  • Will the solution fill a need?
  • Will it fit into people’s lives?
  • Will it appeal to them?
  • Will they actually want it?

Viability (business focused)

  • Will the design solution align with the business goals?
  • Does this solution honor the client’s budget?

Feasibility (technology centered)

  • Is the technology needed to power the design solution available or within reach?
  • How long will this take?
  • Can the organization actually make it happen?

Answers to these critical questions help product-led organizations to justify and prioritize the solutions on the roadmap.

Product-centric working models create objectivity within organizations by centering a set of high value, yet varied, perspectives on an artifact or set of artifacts. They combine innovation best practices and diligent process to create significant business efficiencies by reducing the subjectivity that often plagues innovation cycles. The best practice methods force a clarity by ensuring every decision is tied to the successful delivery of a solution that has value in the eyes of the buyer.

In an ideal scenario, business (Sales/Account Management/Partnerships/etc.), IT teams (Engineering/Data/etc.), and strategic technology partners (Key Vendors/Consultants/etc.) work seamlessly together to quickly deploy features and enhancements for clients and end users with clear measurement and backlogs for potential future functionality. Product centricity brings teams together to deliver solutions that solve customer and business problems with the following benefits:

  • Quick response: Product-centric teams can efficiently and effectively tackle business issues, often rolling out new products and experiences in a shortened amount of time.
  • Cost savings: Thanks to product-oriented development methods, process automation, the elimination of time-consuming handoffs between application development and application management teams, and the guidance of a designated product owner who manages backlogs and prioritizes critical work, product-led teams drive efficiency, and savings as a result.
  • Informed, algined teams: Team autonomy is a by-product of this approach that enables these groups to handle change at an impressive rate. Synchronization between business and IT teams is the centerpiece of value in agility-driven development by creating a continuous feedback loop allowing both sides to complement the other’s efforts.

A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. It is a strategic representation of the capabilities that product and product partners believe will add value and it is a plan for executing the product strategy and the cornerstone of a product-led approach.

It communicates the classification, sequence, and alignment of these capabilities while allowing a variety of audiences to gain insight into the why and what behind what is being built. It also allows these audiences to provide subject matter expertise and market feedback as conversations develop with potential customers.

And throughout the journey from idea to delivery, the roadmap provides a constant touch stone to strategy to help prioritize what to build as markets, customer needs, and competitive landscapes change.

Whether you are a startup looking to define your first roadmap for a product you plan to build or you are a company who has grown organically by delivering on an endless set of client modifications and request for changes, you have determined you need a roadmap. But now what?

There is plenty of software out there to help manage the roadmap but in order to make use of that, you need the inputs. A first time Product Roadmap can be a wicked problem—a problem that gets harder to solve the more you try to solve it—because of lack clarity in both the aims and solutions and the real-world constraints which hinder risk-free attempts to find a solution. And as a result, what feels like it can be a simple process can become quickly overwhelming.

Below is the 10-step approach I typically take to get a first roadmap defined, socialized, and adopted internally and externally.

  1. Constrain: Given the potenital endlessness of a roadmap, the first step is establishing the range and a territory. Like planning a driving trip it is critical to know how far you are intending to travel to be able to predict the obstacles and services you will need along the way. I typically start with “2+ years.” The first 2 years are firm quarterly chunks of time to plan against and the “plus” is the time after that is much more vague and a place to put things that may be interesting but need more definition to confirm the product/market fit.
  2. Ideate: For a first time roadmap, this is typically a brainstorming activity where a few innovators conceptualize all the potential things that may add value in the territory they have defined. Since this is a creative activity, it must be done in a safe brainstorming environment in order to unlock the mindsets of participants. If judgment is levied in this step, it typically constricts the flow of ideas. Therefore, all participants need to buy-in to the methods and practices being used to elicit the roadmap candidates.
  3. Synthesize: With a set of ideas in hand, the next job is to make sense of the ideas and combine them into a cohesive whole. Territory maps, card sorts, and similar methods can be helpful in bringing structure. Typically the structure is a set of lists that group items into capabilities that align to a higher order concept. These can become “lanes” within the roadmap where specific proposed capabilities begin to suggest a feature growth sequence or they can be meta product concepts that group concepts into higher order product benefit categories. It is also likely at this stage to see certain ideas pulled out and placed into a parking lot because an alignment cant be found within the time period or territory in view.
  4. Dimensionalize: With the items organized and classified, the next step is to bring dimension to each item. Ideas should be considered through the lenses of feasibility, desirability, and viability and documented with enough precision so that stakeholders can read, understand, and react. The following questions are typically needed to bring enough context to get value added reactions.
    • What is the product/capability called?
    • What is the two paragraph description of the solution and benefit?
    • Who is it for?
    • Where does it live within the product/platform?
    • How does it help the business financially?
    • How does this align to top organizational goals?
    • What are the milestones and measurable benefits?
    • Who are the departmental owner(s) of the roadmap item?
    • What are the features that may be included to deliver on the strategy?
    • Who might we partner with (build vs. buy)?
    • How many clients do we expect and when?
    • How does this benefit the client?
    • What do we need to scale?
  5. Validate: Once documented, the steward of the roadmap process should convene stakeholder meetings or individual review sessions to gain feedback on the strategies, alignment, and proposed market expectations. Depending on the density of the roadmap, this may take multiple sessions and may require a mix of one on one reviews and group reviews to confirm item value and timelines. As this is the first validation cycle, this is typically internal stakeholders and client representatives. With the published roadmap that results from this first sequence, validation becomes part of the product-led organizations continuous improvement practice.
  6. Sequence: Using the set of strategies and capabilities that have stakeholder buy-in, now you can start to think about the sequencing. This happens on two levels within the roadmap: (1) the sequencing of the broad capability and (2) the sequence of the product building activities within the item. To do this successfully, the roadmap steward needs to keep organizational capabilities and capacity in mind while considering the market expectations to propose a timeline that works for both. I tend to take a quarterly view and start by thinking from the bottom up. I consider first the work needed to develop the capability into something desirable using a Crawl/Walk/Run/Fly approach (Crawl is a Pilot/MVP, Walk is the MMP, Run is a generally available (GA) feature/capability, Fly is an innovation loop following a GA feature) and then sequence items on the broader roadmap. In CWRF planning for a specific item, the objective is to order the work needed to build up to a market viable capability by thinking critically about what work should happen in what order to maximize efficiencies and create testable hypotheses at key milestones. This exercise should also attempt to consider how long each of those chunks will take to deliver so the appropriate spacing between milestones is allowed.
  7. Estimate: Although you have planned out the timeline with the delivery teams in mind and you have worked to deprioritize or push out items to create a reasonable blending of work, it is likely that the organizations appetite is still bigger than what it can support. In the estimation phase, SME product and engineering experts look to previous deliveries for similar work to the scope identified in each part of the roadmap and put a rough estimate on the work in points or hours. If there is no previous estimates to draw against, these SMEs make educated guesses from prior experience. With estimates for each phase of a feature mapped to the quarter where the work is anticipated, each quarter can be summed up to a number of points or hours expected during that period to inform the next step.
  8. Prioritize: At this point, leadership has a fairly robust picture of the product roadmap, the effort associated with delivering, and the expected take rate, and value for the feature defined. The roadmap steward and enterprise leadership can now evaluate the work in context and further prioritize according to a difficulty/importance or time-to-value framework in an effort to deliver the highest value items first. As items get deprioritized out of this process, the work and effort to define them can and should be retained for future use by pushing them further out on the time horizon.
  9. Publish: For product-led companies the product roadmap is a living document that changes with the input and reaction of the market. Making this available to internal departments and customers, creates a single source of truth to focus feedback, publish updates, and plan development. Tools like ProductBoard are critical at this stage because they provide the purpose built solution that can elegantly and efficiently capture feedback and manage progress in a way that spreadsheets, wikis, and shared docs cannot. Those tools are valuable but are supporting artifacts.
  10. Advocate: The last and most vital part of this process is this last one. All the work to done to this point has gotten the product organization to the starting line. To really use roadmaps strategically, the steward of the roadmap and product leadership must create a discipline around socializing and advocating for the roadmap. Internally connecting with client facing teams and externally connecting with clients and end users is essential to ensure the voice of the customer is influencing the roadmap. After all, the products are ultimately for them. Understanding what they value and what they expect is essential to ensure the product arrives in market with a warm reception.



Source link

More To Explore

Share on facebook
Share on twitter
Share on linkedin
Share on email