Product #61
Shape Up, PageRank and More.
Shape Up · Ryan Singer · 2019
Shape Up is an incredibly refreshing read. It’s opinionated, new and different. Ryan does a great job of describing a delivery system that addresses some of the most common challenges in building and shipping software. Adopting the methodology lock-stock-and-barrel will be too much for most teams, but it has you wondering what could I borrow? Great read.
Key Points
Common pain points: Long projects, no time for strategic thinking, velocity falls over time.
Shaping is up-front design work, that sets boundaries and reduces project risk before handing over to development teams.
Shape → Bet → Build.
Shaping
Shape work at the right level of abstraction— somewhere between too vague and too concrete. Words are too abstract, wireframes are too concrete. Shaped work should be rough (allowing team flexibility), solved (well thought through), and bounded (limited in scope).
Shaping defines what the feature does, how it works and where it fits into existing flows. Why does it matter? What would success look like? What customers are affected?
The shaping process involves four key steps:
Set boundaries: Start with the idea, determine its value (appetite), and adopt a fixed-time, variable-scope approach (Small Batch (1-2 weeks) or Full Cycle (6 weeks)). Watch out for grab-bags (refactors and redesigns are the worst offenders). Split these projects into smaller projects.
Find the elements: Move from words to elements of the software solution. What are the key components or interactions? Where does it fit? How do you get to it? Where goes it take you?
Try things at a high level (Breadboard): Places: things you navigate to; Affordances: things a user can do; Connection lines: how affordances take the user from place to place; Elements are the output
Fat marker sketches make it impossible to add too much detail and leaves room for designers
Address risks and rabbit holes: Identify potential pitfalls upfront. Walk through use cases in slow motion to uncover concept holes or problematic edge cases. Consider technical viability. Declare what you won’t do . Shapers prioritise quality and reduce risks. Keep elements that make the project worth doing? Can you cut off the big tail of risk? Keep the clay wet.
Write the pitch: Present the shaped work as a potential bet. Include a problem statement, appetite, solution overview, rabbit holes (problems to avoid), and no-gos (things excluded from the concept).
Betting
Replace backlogs with bets. Hold a betting table for stakeholders before each six-week cycle to review well-shaped pitches. Distribute responsibility for prioritisation across the team. Six-week cycles allow for better resource alignment, with two-week cool-downs between cycles for reflection and unscheduled work.
The betting table is a two-hour meeting with senior decision-makers, resulting in a cycle plan. Bets are commitments with capped downsides. Uninterrupted time is crucial, and projects don't get extended—preventing runaway timelines.
Three phases of work for building new products:
R&D mode: Led by senior members, focused on learning and defining structure.
Production mode: Formal cycles with shaping, betting, and building phases.
Cleanup mode: Structure-free, focused on launch preparation and bug fixing.
Building
Assign projects, not tasks. "Done" means deployed. Teams should spend initial days orienting themselves and discovering tasks through real work.
Get one piece done early, aim for something tangible and demo-able in the first week. Start with a core, small, and novel component.
Map the scopes (integrated project slices of value) to divide the project into territories. Scopes arise from interdependencies discovered during work.
Show progress by shifting focus from completion status to solved vs. unknown issues. Build uphill, tackling the most important problems with the most unknowns first.
Decide when to stop by comparing to the baseline customer reality. Use cycle limits to motivate scope management. Cutting scope isn't lowering quality; it's prioritising what matters.
After launch, allow time for reactions to settle before making further changes. Remember the rationale behind the initial decisions.
Full Book Summary · Get the Book
Quick Links
How vector databases work · Video
A simple 5 step growth strategy · Article
Marketplace PM? Market Capture Framework · Article
The role of systems in decision making · Article
Gamestorming: How Now Wow framework · Article
High velocity decision making (Amazon style) · Article
Product Management vs Product Marketing · Image
The Anatomy of a Large-scale Hypertextual Web search Engine (PageRank)
Sergey Brin and Larry Page · 1998
*In this paper, we present Google, a prototype of a large-scale search engine which makes heavy use of the structure present in hypertext. Google is designed to crawl and index the Web efficiently and produce much more satisfying search results than existing systems. The prototype with a full text and hyperlink database of at least 24 million pages is available at http://google.stanford.edu/.*
To engineer a search engine is a challenging task. Search engines index tens to hundreds of millions of Web pages involving a comparable number of distinct terms. They answer tens of millions of queries every day. Despite the importance of large-scale search engines on the Web, very little academic research has been done on them. Furthermore, due to rapid advance in technology and Web proliferation, creating a Web search engine today is very different from three years ago. This paper provides an in-depth description of our large-scale Web search engine — the first such detailed public description we know of to date.
Apart from the problems of scaling traditional search techniques to data of this magnitude, there are new technical challenges involved with using the additional information present in hypertext to produce better search results. This paper addresses this question of how to build a practical large-scale system which can exploit the additional information present in hypertext. Also we look at the problem of how to effectively deal with uncontrolled hypertext collections where anyone can publish anything they want.
This was clearly the beginning of something exceptional. As a product manager, the clarity with which Larry and Sergey defined the problem space stands out to me. They understood the significance of search, knowing that content was expanding exponentially and scalability was crucial. They designed a system that grew in power and value as the number of users and the volume of web content increased.
Book Highlights
Analysis of hundreds of jobs has revealed that all jobs consist of some or all of the eight fundamental process steps: define, locate, prepare, confirm, execute, monitor, modify and conclude. This insight is essential for creating a framework around which customer needs (desired outcomes) are gathered.
Anthony W. Ulwick · Jobs to Be Done
So as a manager, you have to find what connects with your team. How can you share your passion with them, motivate them?
Tony Fadell · Build
Active learning for recommender systems is about creating an algorithm that comes up with good examples for the user to rate, which then provides the recommender with valuable information about the person’s preferences.
Kim Falk · Practical Recommender Systems
In the cloud world where storage and compute resources are much more elastic, the concern has shifted from how to maximise resource utilisation to how to use resources cost-effectively.
Chip Huyen · Designing Machine Learning Systems
Quotes & Tweets
As you become an adult, you realise that things around you weren’t just always there; people made them happen. But only recently have I started to internalise how much tenacity everything requires. That hotel, that park, that railway, The world is a museum of passion projects
John Collison
Testimonials are a foundation of social proof. But don’t stop there…
Endorsement from opinion leader
Live stats about your customers
Average rating
Seen on (media)
Used by (logos)
Recent sales
Case studies with the best customers
Dan Kulkov
Great review of the shape-bet-build methodology. Very interesting.
I believe great product managers should strive to minimize the "betting". Instead, try to validate as much as you can before the "build" phase. But it's true, there's always some betting.