Product Development

Build – Tony Fadell

Build - by Tony Fadell
Date read: 7/23/22. Recommendation: 8/10.

Such a great book for entrepreneurs and creators. Fadell, the engineer behind the iPod and iPhone, and founder of Nest, reflects on lessons learned over the course of his career. He offers advice on evaluating opportunities, working with executives, disrupting yourself, managing crises, and knowing when to quit and when to stick it out. Throughout the entire book he ties these themes back into his own experiences and advocates for the importance of having skin in the game.

See my notes below or Amazon for details and reviews.

My Notes:

Evaluating opportunities:
“When you’re looking at the array of potential careers before you, the correct place to start is: ‘What do I want to learn?’
Not ‘How much money do I want to make?’
Not ‘What title do I want to have?’
Not ‘What company has enough name recognition…’” TF

“The only failure in your twenties is inaction. The rest is trial and error.” Anonymous 

Tony spent the dot-com bubble building handheld devices. Instead of going to some internet startup, he went to Philips to make devices, then started his own company to make digital music players. Eventually, that led him to Apple where he made the iPod and iPhone. Wouldn’t have had that opportunity if he didn’t stick with what he wanted to learn and what he cared about building. 

“The way I’ve gotten wealthy is not by accepting giant paychecks or titles to do the jobs I know I’ll hate. I follow my curiosity and my passion. Always.” TF

“What you do matters. Where you work matters. Most importantly, who you work with and learn from matters. Too many people see work as a means to an end, as a way to make enough money to stop working. But getting a job is your opportunity to make a dent in the world. To put your focus and energy and your precious, precious time toward something meaningful.” TF

“Students seek out the best professors on the best projects when getting their master’s or PhD, but when they look for jobs, they focus on money, perks, and titles. However, the only thing that can make a job truly amazing or a complete waste of time is the people.” TF

Characteristics of a successful company:

  1. Creating product or service that’s wholly new or combines existing tech in a novel way that competition can’t understand.

  2. Product solves a problem—a real pain point that customers experience daily. Large existing market.

  3. The technology can deliver on the company vision (product, infrastructure, platform, systems).

  4. Leadership isn’t dogmatic about what the solution looks like and is willing to adapt to customer needs.

  5. Thinks about a problem or customer need in a way you’ve never heard before but makes perfect sense once you hear it.

Growth:
Company and personal growth: “Either you’re growing or you’re done. There is no stasis.” TF

Grind:
“But if you want to prove yourself, to learn as much as you can and do as much as you can, you need to put in the time. Stay late. Come in early. Work over the weekend and holidays sometimes. Don’t expect vacation every couple of months…” TF

Skin in the game (avoid consulting):
“Just whatever you do, don’t become a ‘management consultant’ at a behemoth like McKinsey or Bain or one of the other eight consultancies that dominate the industry. They all have thousands upon thousands of employees and work almost exclusively with Fortune 5000 companies. These corporations, typically led by tentative, risk-averse CEOs, call in the management consultants to do a massive audit, find the flaws, and present leadership with a new plan that will magically ‘fix’ everything.” TF

“To do great things, to really learn, you can’t shout suggestions from the rooftop then move on while someone else does the work. You have to get your hands dirty. You have to care about every step, lovingly craft every detail. You have to be there when it falls apart so you can put it back together.” TF

Working with executives with strong opinions:
Ask why: “It is the responsibility of a passionate person—especially a leader—to describe their decision and make sure you can see it through their eyes. If they can tell you why they’re so passionate about something, then you can piece together their thought process and either jump on board or point out potential issues.” TF

When to quit and when to stick it out:
“Most people know in their gut when they should quit and then spend months—or years—talking themselves out of it.” TF

Indicators that it’s time to quit: 1) You’re no longer passionate about the mission. If you’re staying for the paycheck or to get the title you want, but every hour feels like an eternity. 2) You’ve tried everything. You’re still passionate about the mission but the company is letting you down.

“Every meeting, every pointless project, every hour stretches on and on. You don’t respect your manager, you roll your eyes at the mission…It is time and energy and health and joy that disappear from your life forever.” TF

“People won’t remember how you started. They’ll remember how you left.” TF

“Quitting anytime things get tough not only doesn’t look great on your resume, but it also kills any chance you have of making something you’re proud of. Good things take time. Big things take longer.” TF

“Too many people jump ship the second they need to dig in and really push through the hard, grinding work of making something real.” TF

Disrupt yourself:
“If you’re experiencing your biggest market share ever, that means you’re on the brink of becoming calcified and stagnant. It’s time to dig deep and kick your own ass.” TF

“We had to make the iPhone, even though we knew it could, probably would, kill the iPod.” TF

Tesla could have fallen into the same trap—made EV cars attractive. Every other carmaker followed. So they focused on innovating charging networks, retail, service, batteries, supply chains to stay ahead.

Three generations of products to get it right:
Make the product (not remotely profitable. Fix the product (get gross margins right). Build the business (reach net profits). 

Managing crises:

  1. Keep your focus on how to fix the problem, not who to blame.

  2. Don’t be worried about micromanagement. Get in the weeds. During a crisis, your job is to tell people what to do and how to do it.

  3. Get advice. Don’t try to solve problems alone.

  4. Your job once the initial shock is over is to overcommunicate and listen.

  5. Accept responsibility for how it has affected customers and apologize, regardless of whose fault it was.

Working Backwards – Colin Bryar and Bill Carr

Working Backwards: Insights, Stories, and Secrets from Inside Amazon by Colin Bryar and Bill Carr
Date read: 10/8/21. Recommendation: 8/10.

This is a great directional resource for companies to fine-tune their own top-performing culture. Bryar and Carr cover everything from leadership principles and hiring during their time at Amazon to the product development approach, relentless focus on customer experience, and communication processes. I’m a big fan of Amazon’s communication style, favoring narratives (written documents) over slides. While I believe the themes and general concepts found in this book are valuable, when you read books like this there’s always a temptation to apply the entirety of the content back to your own company and experience. But the exact processes and systems that work for Amazon will not work the same way for your business. The real value is using this as inspiration then leveraging interesting concepts or approaches to fit your team.

See my notes below or Amazon for details and reviews.


My Notes:

Amazon’s culture:
“Our culture is four things: customer obsession instead of competitor obsession; willingness to think longer term, with a longer investment horizon than most of our peers; eagerness to invent, which of course goes hand in hand with failure; and then, finally, taking professional pride in operational excellence.” Jeff Bezos

Amazon’s leadership principles:

  1. Customer obsession: Start with customer and work backwards

  2. Ownership

  3. Invent then simplify

  4. Are right, a lot: “Leaders are right a lot. They have strong judgment and good instincts.”

  5. Learn and be curious

  6. Hire and develop the best

  7. Insist on the highest standards

  8. Think big: “Thinking small is a self-fulfilling prophecy”

  9. Bias for action: “Speed matters in business”

  10. Frugality: “Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for headcount, budget size, or expense.”

  11. Earn trust

  12. Dive deep

  13. Have backbone; disagree and commit

  14. Deliver results

Two-pizza teams are:

  • Small: no more than ten people.

  • Autonomous: No need to coordinate with other teams to get their work done.

  • Monitored in real-time

  • Business owners

  • Led by a multidisciplined top-flight leader

  • Self-funding: team’s work will pay for itself

  • Approved in advance by leadership

Autonomous team setup:

  1. Well-defined purpose: “For example, the team intends to answer the question, ‘How much inventory should Amazon buy of a given product and when should we buy it?’

  2. Boundaries of ownership are well understood

  3. Metrics to measure progress are agreed upon upfront

Specifics of how the team will solve its challenge and achieve its goal is entirely up to the team. They must figure that out for themselves.

Narratives:
Six-pager: Describe, review, or propose just about any idea, process, or business. Maximum length 6 pages.

PR/FAQ: Working backwards process for new product development.

“The reason writing a good 4 page memo is harder than ‘writing’ a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related. Powerpoint presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.” Jeff Bezos

Continuous Discovery Habits – Teresa Torres

Continuous Discovery Habits – Teresa Torres
Recommendation: 8/10. Date read: 8/3/21.

This should be a foundational book for product teams looking to introduce stronger discovery habits. Torres emphasizes the principle of outcomes over outputs as being at the heart of better discovery. She starts by walking through how to discover opportunities through visualization exercises, mapping, and continuous interviews. Then she digs into how to discover solutions through ideation and identifying hidden assumptions. It’s in this section that I think she presents her strongest idea and framework which is built around testing assumptions, not ideas. Along the way, Torres also presents anti-patterns that go against best discovery practices so you can identify which pitfalls to avoid.

See my notes below or Amazon for details and reviews.

My Notes:

Opportunity solution trees:
“Shifting from a project mindset to a continuous mindset is hard. We tend to take our six-month-long waterfall project, carve it up into a series of two weeks sprints, and call it ‘Agile.’ But this isn’t Agile. Nor is it continuous. A continuous mindset requires that we deliver value every sprint.” TT

Solving smaller opportunities eventually solves bigger opportunities. 

Instead of asking, “Should we solve this customer need?” Instead ask, “Which of these customer needs is most important for us to address right now?”

Assumptions:
Desirability: Does anyone want it?
Viability: Should we build it?
Feasibility: Can we build it?

Once you have all assumptions listed out, map them on a quadrant. X-axis goes from strong evidence on the left to weak evidence on the right. Y-axis goes from less important at the bottom to more important at the top. Any assumptions that land in the top right corner (weak evidence, more important) are leap of faith assumptions. This gives you an indicator of which assumptions should be tested first. 

Break a product or feature up into smaller opportunities. Each opportunity should then map to assumptions that you are testing. That way you’re learning with each opportunity you knock out. If you attempt to test the whole idea, rather than an individual assumption, there will be too much noise to determine what was actually effective or ineffective. 

“We aren’t testing one idea at a time. We are testing assumptions from a set of ideas.” TT

Radical Focus – Christina Wodtke

Radical Focus – Christina Wodtke
Recommendation: 8/10. Date read: 7/14/21.

The best book that I’ve read on using objectives and key results (OKRs) to achieve your most important goals and focus on what matters. Wodtke advertises this as “a business book in the form of a fable” and its format doesn’t disappoint. Radical Focus follows a fictional case study of two entrepreneurs struggling to keep their startup alive. Throughout the story they find themselves struggling to communicate, not allowing their strategy to evolve, and trying to do too many things at once. The story brings the ideas to life without being overly prescriptive. The second half of the book then provides a tactical guide to implementing OKRs in an effort to help both you and your team realize your most ambitious goals.

See my notes below or Amazon for details and reviews.

My Notes:

Focus:
“A startup’s enemy is time, and the enemy of timely execution is distraction.” CW

“Select only one OKR for the company unless you have multiple business lines. It’s about focus.” CW

Weekly check-ins:

radicalfocus.jpg
  1. Objectives = inspiration for quarter. Key results = what happen if you do the right thing. DO NOT pick more than three key results. Set these with 50% confidence of achieving and every week give them a score out of 10 to assess confidence level. When you kick off the quarter, your confidence would be 5/10. As a starting place, think about usage, revenue, and satisfaction metrics as your KRs.

  2. Health metrics: Sit below objective and key results. These are things you don’t want to forget or sacrifice while you aim to achieve key results. This could be customer satisfaction (don’t want to alienate current customers), team health, code health, etc.

  3. This week: P1s and P2s, write 3-5 big things you’ll focus on this week to affect the OKRs. Don’t list everything you’re going to work on, just the things that must happen or else your objectives will be at risk.

  4. Next 4 weeks, pipeline: Things you expect to happen in the next month so stakeholders aren’t caught off guard.

Example of how this might look:

  • Objective: Establish clear value to restaurant suppliers as a quality tea provider

  • KR: Reorders at 85% (5/10)

  • KR: 20% or reorders self-serve (5/10)

  • KR: Revenue of $250k (5/10)

  • P1: Close deal with TLM Foods

  • P1: New order flow spec’d 

  • P1: Three solid sales candidates in for interview

  • P2: Create customer service job description

Weekly status emails:

  1. Lead with your team’s OKRs, and how much confidence you have that you are going to hit them this quarter.
    -OKRs remind everyone why you are doing the things you do
    -Confidence is a guess of how likely you feel you will meet your key results. 1 is never going to happen, 10 is in the bag. Mark red when it falls below a 3, green when it passes a 7.

  2. List last week’s prioritized tasks and if they were achieved. If not, explains why (goal is to learn what keeps org from accomplishing what it needs to).

  3. List next week’s priorities (pick three P1s)

  4. List any risks or blockers

  5. Notes (hiring updates, reminders about team events, open questions, opportunities to shadow discovery, etc.)

Vision:
“When you are tired of saying it, people are starting to hear it.” Jeff Weiner

Empowered – Marty Cagan and Chris Jones

Empowered: Ordinary People, Extraordinary Products – by Marty Cagan and Chris Jones
Recommendation: 8/10. Date read: 2/4/21.

Anything Marty Cagan touches is likely going to be an incredible, detailed resource for Product Managers. While Inspired focuses on best practices from discovery through delivery in an effective production organization (individual contributors should start with Inspired), Empowered focuses on product leadership. The book highlights the role of product leaders in creating an environment where greatness can emerge through effective coaching, staffing, team topology, product vision, product strategy, and objectives. Cagan and Jones pull everything together with case-studies from top tech companies and leaders throughout the book to show concepts in action. As with Inspired, the emphasis is on creating empowered product teams that have meaningful problems to solve, rather than features to build.

See my notes below or Amazon for details and reviews.

My Notes:

Empowered product teams:
Strong product companies give teams problems to solve rather than features to build. Teams are then empowered to solve those problems in the best way they see fit. Because the best people to determine the most appropriate solution are those closest to the problem, with the necessary skills (the product team).

Output does not equal impact: It’s far better to miss a date and ship something that solves a real pain point and delivers real business results. This is the difference between feature teams (measured by output) and empowered product teams (measured by outcome and results). 

Three characteristics of strong product teams: tackle risk early, solving problems collaboratively, accountable to results. 

Collaboration-based decision-making is not about consensus, not about pleasing the most people (dot voting), and not about having one person who's forced to make all decisions. If the decision is about enabling technology, we can debate, but defer to the tech lead. If the decision is primarily about the user or customer experience, we defer to the product designer. If the decision is about business viability, we defer to PM who collaborates with relevant stakeholders. 

“The essential point of team objectives is to empower a team by (a) giving them a problem to solve rather than a feature to build, and (b) ensuring they have the necessary strategic context to understand the why and make good decisions.” MC

Product manager responsibilities:
Ensure solutions are valuable (customers will buy the product and/or choose to use it) and viable (it will meet the needs of the business). The designer is responsible for ensuring it’s usable. The tech lead is responsible for ensuring it’s feasible. Together this team is responsible and owns results.

“Your highest-order contribution and responsibility as a product manager is to make sure what the engineers are asked to build will be worth building.” MC

Product strategy helps us decide what problems to solve, product discovery helps us figure out tactics that can actually solve the problems, and product delivery build that solution so we can bring it to market. 

The role of managers: 
“If you want to have truly empowered product teams, then your success depends very directly on these first-level people managers. If you are wondering why there are so many weak product companies in the world, this would be the primary culprit.” MC

Critical skills of managers: understand and can communicate product vision, principles, and product strategy from senior leaders. Additionally, have three important responsibilities…

  1. Staffing

  2. Coaching

  3. Team objectives

Coaching mindset:
Developing people is job #1. If you are a manager, you should be spending most of your time and energy coaching, unlocking, and leveling up your team.

Remove impediments, clarify context, and provide guidance. 

Seek out teaching moments to help people stretch beyond their comfort zone and navigate adversity. 

“The best product leaders measure their success in how many people they’ve helped earn promotions, or have moved on to serve on increasingly impactful products, or to become leaders of the company, or even to start their own companies.” MC

Assessing product skills:
Product knowledge, process skills and technique, people skills and responsibilities. See page 41 for full details on what to look for. 

Assess these skills to determine gap analysis (1-10 scale), then provide coaching, training, reading, or exercises to help PM develop in each area. 

Interviews:
“A’s hire A’s, but B’s hire C’s.” A manager who is not an accomplished IC and who hasn’t been on the ground floor doing the work they’re speaking about can’t expect to effectively assess a candidate. As a result, they often end up hiring incompetent people.

Question to assess self-awareness: You’re a product person so I already expect that you’re strong in each. But how would you self-assess the following attributes?

  1. Execution—how well do you get things done, do the right thing without being asked, and track lots of simultaneous targets?

  2. Creativity—how often are you the person in the room with the most or the best ideas?

  3. Strategy—how well do you get up above what you’re working on and put it into broader market or vision context then make this clear to others?

  4. Growth—how good are you at figuring out ways to multiply effort through smart use of process, team management, and so on?

Objectives:
Objective is the problem to solve, key results tell us how we define success. See examples of good objectives on page 276 and page 340. 

Shape Up – Ryan Singer

Shape Up – by Ryan Singer
Date read: 2/12/20. Recommendation: 8/10.

One of the best guides out there for modern product development and the familiar challenges that product teams face. Part one aims to provide a better language to deal with and describe risks, uncertainties, and challenges that define product development. Part two outlines processes Basecamp (where Ryan leads product) uses to make meaningful progress on their products. The book mainly focuses on the risk of getting stuck or bogged down in last quarter’s work, wasting time on unexpected problems, and not being free to do what you want tomorrow.

See my notes below or download a free copy from Basecamp.

My Notes:

Part one aims to provide a better language to deal with and describe risks, uncertainties, and challenges that define product development. Part two outlines processes Basecamp uses to make meaningful progress on their products.

Focuses on the risk of getting stuck, the risk of getting bogged down in last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow. 

Shaping:
Be critical about the problem—what are we trying to solve, why does it matter, what counts as success, which customers are affected, what is the cost of doing this instead of something else?

To set proper boundaries, you will need a raw idea, an appetite, and a narrow problem definition.

Well-shaped work has a thin-tailed probability distribution. Removes as many unknowns and tricky problems from the project as possible. Project should have independent, well-understood parts that assemble together in known ways.

Set the appetite:
How much time and attention is the raw idea worth? Is it worth a quick fix? Is it worth an entire cycle? Would we redesign what we have to accommodate for this? Or is this only worth it if we can pull it off with a small tweak?

Set the appetite. Start with a number and end with a design. This serves as a creative constraint. Estimates are the opposite and leave too much room for error.

Estimates are only beneficial or accurate when a team has done that exact task multiple times before. They don’t account for uncertainty as you’re trying to define what you actually need to do.

You are shaping for a fixed time window. 

Not, “is it possible to do X?” But, “Is X possible in 6 weeks?”

Scope hammering:
Hammer down scope by narrowing the problem definition.

Narrow understanding of the problem by flipping the question from “what could we build?” to “what’s really going wrong?” You want to understand what’s driving this request, where the workflow is breaking down without this feature.

When you get a request to build something, focus on the when instead of why. This will provide more context. “What was this person doing when the thought occurred to ask for this?”

Be cautious of “redesigns” or “refactoring” that aren’t driven by a clear problem or a single use case.

Critically assess the nice-to-haves. Ask, would this feature still be valuable without this?

The scope is right when…

  1. You feel like you can see the whole project and nothing important that worries you is hidden down in the details.

  2. Conversations become more flowing because the scope gives you the right language.

  3. Easy to organize new tasks because you know the buckets they fit into.

“Every project is full of scope we don’t need. Every part of a product doesn’t need to be equally prominent, equally fast, and equally polished. Every use case isn’t equally common, equally critical, or equally aligned with the market we’re trying to sell to.”

Instead of trying to prevent scope from growing. Empower teams with the autonomy to cut back on scope themselves.

Good enough?
“The best is relative to your constraints.”

“We can only judge what is a ‘good’ solution in the context of how much time we want to spend and how important it is.” 

Anchor the point of comparison away from up towards the ideal and instead down towards the baseline. The baseline is the current reality for customers and how they solve this problem today. 

Seeing work in comparison to current alternative will improve morale and sense of progress made. 

Pitch:
Includes problem, appetite, solution, rabbit holes, and no-gos. See page 37 for more details.

Questions to ask at the betting table:
Does the problem matter? 

Is the appetite right?

Is the solution attractive?

What do we build first?
Start in the middle. Find something that’s 1) core to the concept, 2) small enough to complete in a few days and build momentum, 3) novel, meaning, something new that we haven’t worked on which will help eliminate uncertainty.

Choose the most important problems with the most unknowns to tackle first. This will help get you to the top of the hill. Then you can save the most routine and least worrisome items for the way down. 

Inspired – Marty Cagan

Inspired: How to Create Tech Products Customers Love – by Marty Cagan
Date read: 1/9/19. Recommendation: 7/10.

A valuable resource for technology teams that’s tailored to product management. Cagan discusses the principles of strong product teams and breaks down the individual roles–product managers, designers, engineers, product marketing, and other supporting positions. He also discusses the process of getting to the right product through discovery, ideation, prototyping, and testing. At times it can be a bit prescriptive and could use a few more stories to illustrate the concepts and techniques. But overall, worth the read for entrepreneurs operating in this space or those looking for an introduction to technology product management.

See my notes below or Amazon for details and reviews.


My Notes:

The best product teams share three main principles:
1. Risks tackled up front (value, usability, feasibility, business viability)
2. Products are defined and designed collaboratively
3. Focus is on solving problems, not implementing features

Product/market fit: smallest actual product that meets needs of a specific market of customers.

Product Manager key responsibilities (all focused on evaluating opportunities and determining what gets built):
1. Deep knowledge of customer (issues, pains, desires)
2. Deep knowledge of data and analytics
3. Deep knowledge of all aspects of your business (stakeholders, finance, marketing, sales, legal, technical capabilities, user experience)
4. Deep knowledge of your market and industry

Successful product people are a combination of smart, creative, and persistent.

VPs of Product should have these four key competencies:
1. Team development
2. Product vision
3. Execution
4. Product culture

How to organize teams:
1. Alignment with investment strategy
2. Minimize dependencies
3. Ownership and autonomy: build teams of missionaries (they’re force multipliers), not mercenaries
4. Maximize leverage: establish a balance with shared services
5. Product vision and strategy
6. Team size: 3-10
7. Alignment with architecture: otherwise dependencies, slow pace
8. Alignment with user or customer: team focused on buyers should be different than the team focused on sellers
9. Alignment with business

Management’s responsibility is to provide product teams with business problems, objectives, and vision (NOT solutions). Let the team figure out the best way to solve the problems.

Product Discovery:
Collaboration between product, UX, and engineers to tackle risk before writing production-quality software. Outcome is a validated product backlog.

Purpose is to address value, usability, feasibility, and business viability risks.

Goal is to gain deeper understanding of customers and validate product ideas (qualitatively and quantitatively).

Dedicating time to framing the problem and communicating this can make significant difference in results.

“But one of the most important lessons in our industry is to fall in love with the problem, not the solution.” MC

Opportunity Assessment Technique:
1.
What business objective is this work intended to address?
2. How will you know if you succeeded?
3. What problem will this solve for customers?
4. What type of customer are we focused on?

Customer Letter Technique:
Product manager writes an imaginary press release or letter from hypothetical perspective of a customer talking about how it has improved their life.

Product Opportunities:
Assess the market and pick lucrative areas where pain exists. Or look at what technology enables and match that up with a pain point. Or encourage customers to use products to solve problems other than what you planned for.

One of biggest innovations at eBay was watching how customers used platform to sell things the team never would have imagined (concert tickets, fine art, cars). Built capabilities to facilitate these types of transactions after demand was established.

Customer Interviews:
Always be working to understand if your customers are who you think they are, if they really have the problems you think they have, how they solve the problem today, and what would be required from them to switch.

Prototypes:
Provide the ability to learn at much lower cost (time and effort) than building the full product.

Always ask, “what’s the fastest way to learn this?” MVP should be a prototype, never an actual product.

Benefits of prototyping: forces you to think through the problem at a deeper level, team collaboration, quickly assess one or more of the product risks.

A/B Testing:
Optimization A/B testing: Small changes, different calls to action, colors, fonts. 50/50 distribution. Conceptually similar.

Discovery A/B testing: Big differences, different concepts. Live-data prototype shown to 1% of users or less.

Necessity leading to invention:
In the early days of Netflix they had the same model (pay per rental) as Blockbuster. One of the many tests they ran was to assess customer interest in a subscription service (monthly fee for unlimited movies). They generated significant interest but created more problems in the process of bringing it to life. Most people wanted to rent the newest films which was prohibitively expensive. Netflix needed to get people to ask for a blend of old/new (inexpensive/expensive) titles. This was how the queue, rating system, and recommendation engine were born.