Strategize - Notes and Highlights
(Product Strategy and Product Roadmap Practices for the Digital Age)
It has all the famous frameworks and execution plans on how to create a winning product strategy and roadmap and implement it successfully
Basics:
The product strategy should be updated every quarter, taking into account a mix of business needs, market needs, features, and differentiators.
The strategic foundation comprises of four key elements: Vision, Product Strategy, Product Roadmap, and Product Backlog.
A compelling Vision should be big, shared, inspiring, and concise, providing a clear direction for the product's development.
Innovation can be categorized as Core, Adjacent, or Disruptive, depending on the degree of market vs product newness. Disruptive innovations offer better and more convenient solutions to market needs at a cheaper cost.
The first product iteration should aim for a 'good enough' level of quality, with the specific definition of 'good enough' varying depending on the type of innovation pursued. Disruptive innovations require a lower bar, while Core innovations demand a higher bar.
After the product's launch, the primary objective is to achieve Product-Market Fit (PMF) and transition into the growth stage.
The Product Life Cycle (PLC) consists of five stages: Development, Introduction, Growth, Maturity, and Decline.
Innovators, Early Adopters, Early Majority, Late Majority, and Laggards represent different customer segments in the adoption of a new product.
To successfully cross the chasm between early adoption and mainstream market acceptance, the product must be continually improved to suit the growing market and appeal to the "early majority" section.
Business needs may include opening up new revenue sources, achieving profitability targets, reducing costs, or expanding product offerings.
Various business revenue models, e.g. bait and hook, freemium, subscription, and ad-based, can be employed to monetize a product or service.
Selecting the right Key Performance Indicators (KPIs) is crucial, avoiding vanity metrics and focusing on meaningful and actionable indicators (aka SMART KPI). The KPI should be less but good. The KPIs must be adjusted as per product's phase in the product lifecycle.
KPIs can be classified as lagging indicators (such as code complexity) or leading indicators (e.g. team motivation). Leading indicators provide insights into the 'why' behind the metrics." Both leading and lagging indicators are based on what is the main outcome we want to predict.
Balanced scorecards are useful for measuring the product's performance against business goals.
A bi-directional approach involving Business Goals, Product Goals, and Sprint Goals ensures alignment between overall business objectives and day-to-day product development efforts.
The Power Interest Grid aids in effective stakeholder management by assessing the interest level and power of various stakeholders.
Updating the product strategy requires considering factors such as product performance, competition, company direction, and trends/regulations in the industry.
Part I: Strategy development
Segment, Target and positioning:
Segment -> based on demographics, psychographics, behaviour, geography, industries, company size etc. segmentation can be product benefit offered wise (disruptive or adjacent) or customer property wise (core)
Targeting -> GE/ Mckinsey matrix (attractiveness of segment - y axis, product strength to serve the market - x axis) when measuring attractivenes of a segment, you can also use porter's 5 forces (buyer, supplier, competition, substitute, entry barriers)
Positioning -> create persona for the target and position / design the product to solve the need of the persona (painkiller or vitamin)
benefit > cost / effort for this to function.
Also try to remove all the usage barrier which can reduce your product's attractiveness ... for example apple offered ms office on macbooks.
Select a primary benefit always.
Between a user and customer -> prioritize the user
use strategy canvas (factors x axis, offer level y axis) -> find a blue ocean with some factors atleast
or Kano model (performer, delighters, basics)
Eliminate - reduce - raise - create grid
Create an amazing customer experience irrespective of your product features (by analyzing the customer touch points throughout from installing till uninstalling, from knowing till cancelling the deal). Do it at each product lifycycle stage
Product unbundling: (for ex. create fb messenger app separate from fb app)
To create new product variants has folllowing benefits:
extends market to new customers
simplifies the original product
google unbundled google drive into sheet, slide and docs
Drawbacks: too many options confuse users, can cannibalize main product, portfolio management is needed because of dependencies
Product bundling:
creates more sale value per customer
supports smaller products which can't be sold separately
creates a product environment (network) which traps the customer
Drawback: too bloated so reduces performance, too expensive so not worth the benefit ... the experience should be harmonized to create confusion
keep company brand and product brand harmonized as well (google uses google brand name with sub-product brand such as google maps, google search etc.)
Part II: Strategy validation
It is needed before implementing the new strategy so as to decrease risk of a not successful product strategy.
Testing product strategy:
Select biggest risk in your strategy -> research with customer, MVP or historical data -> analyze and make changes to your strategy -> take next big risk -> repeat cycle till no big risks remain
(the exact cycle is select -> decide how to address it -> collect data -> pivot, persever or stop -> select once again)
Who helps in product validation? -> sales, marketing, legal, devlopers, testers, ux designer, product manager
Use data to make decisions -> reduces biases, supports arguments, gives ideas
turn failure to opportunity -> fail to learn, fail fast, crate fail-safe cultures where failing is not criticized, google's 20% rule, internal hackathons
ask the users, see the environment where the product will be used (do it yourself rather than through agencies or third parties ... if you can't understand the user, you can't solve their problems (once per quarter). Even recruit a test / focus group to ask the questions.
Successful product is at entersection of
right market and needs
right features and technology
right business goals
play the red dot game with team to validate and find the biggest risks in the strategy
setup right validation techniques
right user group
right KPI (quantitative + qualitative)
go for quicker and cheaper tools (paper prototype vs real one if possible)
use problem interviews and user observations
5 to 10: 15 min interviews (small gift voucher at the end)
Create MVP (Minimum viable Product), it can be anything, fake product, website, blog, paper model etc.
create spike products (only partial products which can help analyze the potential risk)
Pivot, persevere or stop (pg 201)
Agile techniques to validate strategy
Time boxing the work
kanban boards (risk -> to do tasks -> task status)
regular review meeting (weekly or bi-weekly)
Part III: Product Roadmap
Strategy decisions ->through product roadmap -> actionable plans
Roadmap foundations: Product roadmap communicates how a product is likely to evolve by mapping its major releasses onto a timeline based on overall product vision and strategy
Roadmaps can be feature based or goal based (with features as secondary level serving the goals
first create simple paper baesd or excel based roadmap and then only try a tool to visualize it. Doing it the other way round doesn't work many times
Roadmap selection matrix (dynamic or stable market vs young or mature product)
max duration of 1 year and max review interval monthly or quarterly
Roadmap stakeholders: Management sponsor, users and customers, service and support, product owner of related product, sales rep, marketing, develop teams, product manager, legal, security and compliance teams
A product roadmap guides the work of all the various stakeholders towards achieving the product roadmap goals as per the roadmap
involve stakeholders in roadmap creation and regular reviews (they might not be happy all the time, but they should agree to the overall roadmap)
3 most common roadmap mistakes:
no guarantee - it is just a growth plan based on current known information. It is bound to change. Keep it abstract enough that it doesn't change very frequently but also flexible enough that it can change as per need and feedback
no speculation - always first create strategy then a roadmap. If you don't have enough content to create a strategy, roadmap is just waste of time... rather wait till first release till answers are more clear
no epics and user stories - clutters, makes it difficult to agree for all stakeholders, competes with product backlog items, changes and people lose trust
Roadmap development:
make your roadmap SMART (specific, measurable, agreed, realistic, time-bound)
Use goal based roadmap (revenue, customer acquisition, employee engagement level etc) rather than feature based (feature A and feature E release)
capture roadmap with GO template (Time frame, release name, the release goal i.e. reason, features to meet release goals (5 features per release is good enough), metrics to measure release goals). Also cost targets can be added extra if needed.
adapt next releases based on feedback from current releases so as to show product growth towards final vision and fill the gaps and complaints
prelaunch releases (beta versions) when it takes more than 6 months to create first minimal product. This way, you can still show progress without showing the first minimal product. min. quarterly releases should be targeted
tasks -> user stories -> epics -> features -> product
between features, select the ones which give you best ROI at the point
always question a new feature if it is really need at that time. Cluttering product with not carefully selected features will lead the product to a failure.
Primary success factor:
do impact analysis for various type of failures (missed release date vs budget over-run vs bad performance etc.). Prioritize the factor which has the most impact on your product future
The iron triangle: goal/features vs budget vs time. All three can't be locked down. One needs to be flexible of the three unless the quality is compromised which is definitely not allowed for long lasting benefits. Select the second success factor of the three from iron triangle.
Brook's Law: Adding manpower to a late software project makes it even more delayed (because hiring, and upskilling and team chemistry takes time so first productivity decreases rather than increases)
If it is not possible to get an acceptable trade off between the three, you need to redesign your product strategy where a more feasible roadmap is possible
First decide the next release date. This time frame is the window of opportunity and then design your product goals and features considering that and MVP.
Use a fixed time cadence (steady release):
simplifies and improves planning process
customer confidence as product is regularly enhanced
a high release cadence might make the competition difficult for others
Even if public release are not possible always, keep releasing internal releases on test versions to keep measuring performance and getting valuable feedback.
cost estimations are beneficial for two things:
helps understand if the product is economically sensible to make
if it is economically feasible to create (resource crunch)
If cost estimates are too high or roadmap unrealistic
either pivot (adjust the roadmap)
or change the product strategy
Types of dependencies
between product releases (plan it in the roadmap then)
on people (try upskilling, creating stable teams or reducing no. of parallel projects)
on technology or other products (break dependencies so that products are loosely coupled with each other using unbundling, bunding or creating shared assets or platform)
Conway's Law: The more complex the developing organization setup, the more are the product dependencies. scale controllably, stepwise and have the right team setup
Product roadmap changes because of (product strategy change, customer user data, work progress)
new ideas
new competitors
new technologies
wrong estimations
Track progress using
Release burndown chart - scrum based process
cumulative flow diagram - kanban process
Do a route cause analysis if progress is not as needed
use the primary success factor and secondry one to take the right action and then update the roadmap
Changing / updating roadmap
roadmap review matrix: young vs mature product, dynamic vs mature market. Range 1 month to 6 months
if roadmap updates are more frequent than 1 month, it means too many details in roadmap
involve the stakeholders
always consider pivot, persevere or stop (start from scratch)
Part IV: Portfolio Roadmaps
it is defining combined roadmaps for multiple products considering their dependencies on the same time frame but separate product wise using GO roadmap (time frame, name, goal, feature, metrics).
have another portfolio manager to manage between the various stakeholders