In case you haven't heard, Citi recently lost $500M due to a poorly designed UI.
And no, it's no April fools joke, nor clickbait. It's a cautionary tale.
Understanding the user and defining the right user stories and acceptance criteria for the development of the product are vital.
Here's a deep dive into:
Crafting a solid acceptance criteria for user stories.
Actually connecting your product team with the user.
Choosing the right product metrics and knowing when decisions don't require mathematical proof.
Uroosa Hippargi via Product Coalition
Lists. You go through school, work, and life, creating lists of requirements to avoid forgetting what matters. The same applies to developing a feature. It's called acceptance criteria, and it'll set the standard to ensure you build great user stories.
It defines what should be in the scope, and what shouldn't.
Part of the success of product development is attributed to achieving goals. But projects typically fail because they aren't in sync with the business side. In other words, it all starts with clear communication and requirement planning, and this is also where the problems often begin.
Delivering the right functionality depends on how well the user story was planned. Acceptance criteria is what will detail the functionality expectations, and what 'completed' means in terms of requirements, removing ambiguity for your team and QA.
Collaboration. How, and when?
Perspective: Ensure it's always written from the user's point of view.
Who writes it: The product manager or product owner.
Who reviews it: All criteria is to be reviewed by everyone and confirmed.
When: It must be written BEFORE the PM/PO considers it ready for sprint planning.
Stakeholder-development team consensus.
Stakeholders: Understand the outcome of each feature.
Development team: Understand the expected behavior of the feature.
Keep it simple.
Expressed with simple language. Clear and concise. Avoid 'and, but, or' usage.
Include only functional and non-functional criteria. No unwanted details.
Make it testable.
Acceptance criteria form the basis of all user story testing. Each criterion must be testable and should have clearly defined success or fail benchmarks. It can only be defined as complete once every criterion has been tested and accepted.
Use a format that fits your needs.
Scenario-oriented: 'Given, when, then' format mimics the user expectations.
Rule-oriented: A checklist. In some cases, we are working with inner system-level functionalities that don't fit the GWT structure.
Get a full overview of how each of the examples works right here👈
[Read] Stop playing the telephone game
Just like setting an acceptance criteria, a key part of building products is to understand user problems. The problem is that most companies (maybe including yours?) have a conveyor belt approach where product teams get requirements from customer-facing teams. This needs to stop, along with product teams being the gatekeeper to discovery.
[Read] Choosing, refining, and tracking product metrics
A reason why great product teams often build products that fail to make an impact is that they don't select the right metrics to measure it. It's never one-size-fits-all, and your product team should be addressing questions about the value your user sees as well as for the overall business.
[Read] Great PMs let fires burn
A good product manager is a firefighter. A great product manager prioritizes and finds leverage to reduce destruction. A Facebook PM gives insights on how to tackle the role on a daily basis. "If you spend all your time extinguishing fires, you may miss critical opportunities to build your business. You’ll be all reaction and no action."
Shreyas Doshi via Twitter
Product management is an art and a science. Great PMs understand that we build products for other humans. Follow this thread to avoid falling into the "data-driven" label pitfall.
We need to stop pretending that *all* product decisions require mathematical proof.
— Shreyas Doshi (@shreyas) March 30, 2021
Trust me, it's fine to use instinct & creative insight for major product decisions.
And if you like moving fast, it's often required.
The trick is when to do it, who does it & how it gets done.
Ask a product manager what makes for a good product strategy. You won't get two identical answers.
More often than not, product teams don't have a clear understanding of what (their) strategy is, and aren't fully aware of it.
It's easier to spot this when they struggle to prioritize product decisions. These difficulties are rarely an execution issue, but a strategy one.
How can we prioritize decisions when there's no clear guidance on how to do it?
To pinpoint and fix strategy issues, you need to have a complete product strategy stack that bridges company objectives and product delivery.
Here are some thoughts on:
Building a complete strategy stack, spotting mistakes, and case studies.
Airbnb's rapid response as a result of a strong mission. Google's vision framework.
Setting the right goals, and how cross functional leaders converge.
Ravi Mehta and Zainab Ghadiyali via Reforge
Strategy shouldn't be an ambiguous concept, it's a system formed by a stack of 5 components (company mission, company strategy, product strategy, product roadmap, product goals) building upon each other, and their unique relationships. Here's how the system works.
Goals = Strategy
There isn't a universal definition for these terms, but organizations often fail to ensure that there's a common understanding. Strategy is a plan to achieve your goals. How will your team win? Your goal is what a win will look like.
Goal: Increase revenue by 30%
Strategy: Tap into new markets or underserved category.
Hitting goals = Fulfilling strategy
Achieving goals doesn't mean progressing on strategy. Focusing solely on goals leads to losing track of strategic progress.
Goals: Could be defined in a vacuum or on wrong assumptions.
Strategy: Is affected by external factors such as market conditions.
Product strategy = Company strategy
A commonly mistaken assumption by product leaders. It is central, but not the only driver. The company needs to align it to other functional strategies to gain traction and position the company.
Goals first, then define roadmaps
Thinking about our goals first and making the roadmap secondary, can be rarely pulled off correctly.
Teams: Tend to do whatever it takes to hit short-term goals, sacrificing features that pair up, good UX, and even long-term progress for quick gains.
Goals: Should emerge from a roadmap designed to deliver value to the user. This empowers teams to move from trial and error to customer-centric development.
Great stacks: Have a clear structure of components stacked in order: Mission, company strategy, product strategy, product roadmap, product goals.
Incomplete stacks: Are missing a few components such as company or product strategy. This eventually leads to misaligned team priorities, resulting in products shipped with ambiguous strategic direction.
Poor stacks: Missing components, but characterized by components being created in silos, and lacking connections. This results in difficulties setting goals, and reflects a lack of strategic understanding from managers.
You might be asking yourself, how does it all blend together into a tangible example. Here are Slack, Discord and Clubhouse's product strategy stacks.
[Listen] Airbnb's Brian Chesky on rapidly adapting to deliver value differently
An instructive never-heard-before account of the lessons learned after shrinking and navigating a crisis, re-thinking the product and working from a clear mission and the data collected until then, as well as using their S1 as a strategic roadmap.
[Swipe file] Google's building a shared vision framework
In case you're looking to brush up on the highest level of your product strategy stack, here's a 5 component framework to guide your team and develop concrete strategies and deliverables to achieve your mission.
[Event] Netflix's Product Strategy with Gibson Biddle (Former VP Product @ Netflix)
Join this talk on April 1st, where Gib discusses three frameworks to define your product strategy. He will actually show how to make them work while presenting a mock 2021 product strategy for Netflix. Last but not least, he'll use two current Netflix case studies to show the impact of strategy in day-to-day decision-making.
[Read] Goals for alignment, not bonuses
Goals are seen as guidance and purpose, and empowerment. But done wrong, they can easily separate your organization. The idea is to decentralize and empower teams. There are three areas that are key to doing so: Organizational design, the cascade of goals, and the need to empower with goals.
Julie Zhuo via Twitter
Your company's success is highly driven by the quality of your product. The pressure is on, but being able to snap out of the silo mentality and align with cross-functional teams and their strategies will go the extra mile to position for market leadership.
I've participated in too many conversations about the role of design / pm / eng to count.
— Julie Zhuo (@joulee) March 25, 2021
Of course there are differences.
But every tech manager role, regardless of discipline, ends up converging at higher levels.
What does this mean for you as a manager?
Thread below 👇
A quick history lesson:
A hundred years ago a product pioneer found a different way to product-market fit.
When asked about it, he said: "If I had asked people what they wanted, they would have said faster horses."
Products were a bit different back then but the premise remained the same.
There's no one way to connect value to your roadmap; there are many.
Each 'right way' to address a user problem will come with its own set of difficulties - the delicate equilibrium between value, feasibility, and viability.
So whether you're Henry Ford reinventing mobility, or iterating on an existing product, don't just listen to your customers and don't deliver solutions.
Understand problems, quality balances, and how to measure opportunities at each lifecycle stage. Below is a comprehensive way to do it.
via Des Traynor
The basics say that a company's true goals are on the roadmap, but Intercom has 5 ingredients to scale the scope of their product.
New ideas: They're counterintuitive and almost asking you not to do them.
Customers won't be asking for them.
Data won't support them as they are unprecedented.
Hard to make a case for, as they are likely to fail.
You can either innovate or you can predict performance, not both. Get ideas to exploration without going through an extreme rationalization process.
Product iterations: Using the cupcake principle.
Start small, establish a feedback loop, and scale it up.
Every new feature brings its own roadmap. Ship, get feedback, repeat.
Customer problems: Find the root-cause of the problem.
Customers have expertise in their problem.
But they speak only in terms of pre-conceived solutions.
Can't predict future behavior and tend to overstate or understate importance.
Improving quality: Understand the quality, importance, satisfaction, frequency tradeoffs.
Quality: how well executed is it.
Importance: how important in the workflow is it.
Satisfaction: how happy are users with it currently.
Frequency: how often do they use it.
🚨 Questions for you:
New ideas: What new ideas have you rationalized to death?
Product iterations: What features did you ship and never revisit?
Customer problems: What features did you ship without really considering the problem?
Improving quality: What features are under-used or under-adopted in your product? You can increase usage frequency or increase adoption.
Watch Des Traynor digging into Intercom's roadmapping practices here. 👈
If you're still stuck in the mindset of what feature to ship next, you might want to shift the question to "what is the most important opportunity we should pursue right now?". Opportunity decision trees provide a holistic approach to discovery.
What is it: Similar to story mapping, it's a visual plan to reach a desired outcome. It follows a non-linear organization of ideation of opportunities and solutions through experimentation and gap identification.
How does it work:
1) Identify your outcome(s). Select one metric or OKR you'd like to improve. Make sure there's alignment or the whole exercise won't work.
2) Opportunities should emerge from generative research. Frame the needs and pain-points of your customers as opportunities. Dive deep into each opportunity. What did we learn about our customers and their problems?
3) Solutions can and should come from everywhere. BUT only consider solutions that help us deliver on one of our target opportunities. If they don’t align or connect to the tree, they should be deemed a distraction.
4) Experiment to evaluate and evolve your solutions. Test a single solution. Dedicate your experiments their own row on the tree, and test only the riskiest assumptions, not the whole solution.
PM gaps it solves:
1. We don't fully examine ideas before committing to them.
2. We don’t consider enough ideas.
3. We don’t multitrack in a systematic way.
4. Our solutions don’t connect to an opportunity or our desired outcome at all.
Discover how to set up an opportunity decision tree here.
[Read] What software/tools do you use most regularly to do user research?
In case your team is trying to do user research (hopefully the case), here's a full breakdown of what teams are using. From surveys to prototyping, there's a different one for each use-case. Just like a chef in the kitchen, always make sure you're using the right knife.
[Read] Speed is the killer feature
"I want slower products". Said no customer ever.
Speed is a key differentiator for products that control the market. A user will rarely tell you they want a faster product; it's expected. And somehow, teams continuously neglect this aspect and default to adding more features instead. This article outlines how to assess where speed is most important.
[Read] Designing the smallest possible thing
We all love finding actionable posts and this is one of them. It delves into designing with a continuous discovery mindset. This is how agile teams move from "design everything at once" to breaking things down into shippable chunks, finding how to deliver value in short sprints.
No matter how experienced you are, keeping a daily checklist like the one below will keep you on your toes. Copy the full list, and grab more inspiration from different PMs in this thread.
A handy daily checklist for PMs to keep their team executing at peak performance:
— Lenny Rachitsky (@lennysan) March 8, 2021
✅ Does everyone know what they should be working on?
✅ Are there any blockers currently blocking anyone on the team? Will there soon be?
✅ What decisions need to be made this week?
(more 👇)
Last week we talked about the struggles of eCommerce PMs, but no matter what vertical you're in, fast improvement and scalable execution are always a struggle.
To some, it's a process of short steps and constant iteration, and for others, it involves judgment, some gut feeling ,and intuition, while constantly shipping big bets.
One thing's for sure: projects that entail 6-12 months of work are grueling, and failure is common. But then teams like Stripe come along, and prove it's all possible.
Building products that are consistently better and stand out from anything on the market is rare. Here are some insights on building frameworks to make it possible:
Shipping big product bets, how great teams scale and deliver innovation
How product analytics maturity feeds a product-led strategy
Using data to build products your users want, and using dependencies
Andy Johns and Matt Greenberg via Reforge
One of the dirtiest secrets of most great product teams is that they still follow a waterfally system to consistently launch innovative products and initiatives.
It serves as an argument against the overreliance on agile or lean processes. Short timelines and iterations are safe but prevent from shipping big bets consistently, and fosters a culture of uncertainty avoidance - inherent to innovative ideas.
“High-performing product teams don't religiously subscribe to one tool for all problems. They recognize that through a company's lifetime, different problems arise that each requires a different tool.”
Problems of new dimensions: Arise as the product gains traction and the company grows, such as channel saturation increasing CAC, diminished available target market, and need for larger absolute gains to maintain % growth, to name a few.
Strategies must evolve: The focus shifts from acquisition to engagement, but once the gains from engagement start decreasing, only meaningful innovation can overcome diminishing returns.
Scaling product delivery is messy: Uncertainty, risk manifest,misalignment and cannibalization will undermine your path from strategic idea to final outcome. So recognizing the signals of unscalable product execution is vital.
Building a specific system for large product bets is key to consistently ship innovative products, but since there isn't a one-size-fits-all, here's a detailed description of all the steps you'd need to create this system.
How many times have you heard "we don't have enough reliable data"?
Can you pinpoint your product's "aha moments"? What are the characteristics of your top users? Have you correctly identified user success factors and drop-off?
It's not just a common issue among startups. But it means "product analytics maturity is not a priority" and that you're potentially missing out on reducing time to value, and feedback loops responsive to your customer needs.
Gaining a crystal clear view on how your product creates value for different users is much more attainable than most think.
Wherever you are in your product analytics maturity, layering in a data-driven approach should become the foundation and accelerator of your product. Here's how to implement, and recognize the key indicators to progress at each stage.
[Watch] Making safe bets with good data: Build the products you know customers want
If the articles above weren't enough, here's a great real life example from Jaime DeLanghe (Slack). She'll take you along the journey of using customer insights throughout your data maturity process, and how to act during the different phases.
[Watch] Dependencies - A 5 Minute Overview. Challenges | Mapping | Types
Most teams should have at least a few big bets on their roadmap. But in order to ship ambitious products and initiatives and scale, cross-functional teams need to be able to overcome challenges such as dependencies, timelines and plans.
Shreyas Doshi via Twitter
Don't you love it when generic-looking tweets come packed with hidden easter eggs? Should you build what users say they want? Should you not? What has a heavier weight, your growth pace, your learnings or your product's reliability? It's never a generic solution to problems or one single way to build the right product. Read the whole thread below👇
Why product management is hard
— Shreyas Doshi (@shreyas) February 14, 2021
(and why good product management matters)
1/15 👇🏾
It makes no sense.
PMs spend countless hours trying to build the best version of their vision - researching, managing insights, prioritizing, only for the roadmap to fail its purpose.
It's about where your product is, where you want it to be, and how you'll get there. Not a feature wishlist.
Today's digest is all about building a roadmap that enables great products. In case you need an update on product roadmap best practices, start reading here.
Scroll down for some expert takes on:
How to approach the roadmap correctly.
How vision and roadmaps align teams. Tackling the uncertainty of development cycle alignment, and re-prioritizing.
PRD's with examples, learnings from silicon valley product group, and 25 years of product summed up.
via Malte Scholz and Gibson Biddle
The basics:
Short-term focused and flexible: Any outcome-based roadmap is only as effective as the learning process behind it. Ideally, it should be ready to respond to strategic changes, and ongoing findings about your users. It's not a long-term features release plan.
Visual communication tool: In the words of former Netflix CPO Gibson Biddle "Your roadmap is a story-telling device that details how things might play out over time". In other words, your vision is always present among your high-level initiatives.
Collaborative: Sounds basic, right? Your roadmap should NOT be created by a PM in a silo. PMs in empowered teams make decisions, but listen to the input of their cross-functional teams.
How are you handling your roadmap and what questions do you have? Join the discussion on LinkedIn.👈
Read the full article on Built In
“Roadmaps can and should change, but the vision itself must remain consistent.”
The strategies to stick to the product vision vary, but the goal remains the same: Maintaining a constant evolution so that product you provide your customers, is the best one possible.
Vision simplified:
It's where you want your product to be in the future. Ensure everyone's onboard.
Keep your roadmap high-level as a reminder of your vision.
Milestones- You'll need short-term, and long term ones.
It'll require you say "no".
Always keep in mind the "why" behind your vision. Why did you create it?
While changes in a product roadmap are bound to happen, the consequences of changing priorities mid-development will translate to lost time, and interrupted workflows, which can be crippling. That's why, team alignment from the start is non-negotiable. Especially with remote teams.
Development cycle alignment: "If a requirement is missed or a design task or development story gets booted to a later sprint, the roadmap can easily go awry. To mitigate this risk, a product owner should over-communicate progress and needs." Vinny Pizzimenti - Squarespace.
On re-prioritizing: "Regularly incorporate input from analytics, testing and customer feedback into feature-level adjustments. As product managers, it’s easy to assume that the rest of your team understands the decisions behind certain changes as well as you do. But building alignment around a roadmap in flux means taking the time to explain why priorities have changed." Narguess Noshirvani - Work and Co.
Find out how 26 tech product leaders are tackling these uncertainties, right here.
[Copy] Kevin Yien's product requirements document template (PM at Square)
Before committing to a product or initiative you'll want to define its value and purpose. If you can't tie your product goals to your requirements, those of your users, and how they'll interact into this short doc, you might want to reconsider.
File > Make a copy. You're welcome.
[Read] Product vs. Feature Teams by Marty Cagan
Marty Cagan breaks down the differences between outcome-driven product teams which are a rarity, and the great majority of teams in the feature team model, and how to break away from it.
[Watch] 20 Years of Product Management in 25 Minutes by Dave Wascha
2:30 Listen to customers (for user problems)
5:00 Don't listen to customers (for solutions)
6:23 Watch the competition (for customer research)
8:40 Don't watch the competition
Emil Kabisch via Twitter
Emil is waging a war against traditional roadmaps, giving a startup PM's view on why they don't serve their purpose, and five alternatives that enable the roadmap to be used as part of a process that harnesses new opportunities as findings arise.
Product roadmaps are one of our most important communication and planning tools. Yet crafting a strategic roadmap is one of the most challenging tasks PMs face.
— Emil (@emilkabisch) January 22, 2021
5 ideas on how to escape the feature roadmap trap and do more strategic product planninghttps://t.co/WNqi5YlkY1
1/6