Inspired: How to Create Tech Products Customers Love

Booknotes

Part I — Lessons from Top Tech Companies

It doesn’t matter how good your engineering team is if they aren’t given something worthwhile to build.

There is a tremendous difference between how the best companies produce products vs how most companies produce products.

Most companies are using old and inefficient models to discover and deliver products.

Life is too short for bad products.

Chapter 1: Behind Every Great Product

The strong belief is that behind every great product there is someone that is working hard to lead the product team to combine technology and UX design to solve real customer problems in a way that meets the needs of the business.

Chapter 2: Powered Products and Services

Focus: Unique issues and challenges associated with building technology-powered products/services and experiences

Companies we’ll explore are:

• Consumer Service: Netflix / Etsy / Airbnb
• Social Media: Facebook LinkedIn or Twitter
• Business services: Salesforce / Workday / Workiva
• Consumer devices: Apple / Sonos / Tesla
• Mobile applications: Instagram / Audible / Uber

Technology products do not need to be purely digital.

The examples are blends of offline and online experiences.

Companies that do not do this are rapidly being disrupted.

Chapter 3 Startups — Getting to Product-Market Fit:

In the technology world there are generally 3 stages of companies:

Startups:

• New product/company that is yet to attain Product Market Fit
• The startup is still trying to create a product that can power a viable business
• The PM role is usually covered by one of the Co-Founders
• Typically there are fewer than 25 engineers with one product team
• The reality of startup life is that you are in a race to achieve PMF before you run out of cash
• Nothing else matters until you can come up with a strong product that meets the needs of an initial market so most of the focus of the young company is necessarily on the product
• Startups usually have a limited amount of funding to determine if the company can discover and deliver the necessary product
• The closer you get to running out of money, the more frantic the pace and the more desperate the team and founders become
• While money and time are tight. Good startups learn to move quickly with little bureaucracy to slow them down
• Very high failure rates of tech startups are no secret
• Most that succeed are good at product discovery.
• Working at a startup/racing towards PMF
• If things go well this can be financially rewarding

Chapter 4 Growth — Stage Companies: Scaling to Success:

• Startups skilled and fortunate enough to get to product-market fit are ready to tackle another challenge
• How to effectively grow and scale
• It’s a good problem to have
• Hire more people
• Replicate earlier success with new adjacent Products and services
• Grow the core business as fast a possible
• In the growth stage, we typically have between 25 and several hundred engineers
• Signs of organizational stress are everywhere
• Product teams — complain that they don’t understand the big picture / struggling with what it means to be an empowered and autonomous team
• Sales /Marketing — complain that their go-to-market strategies that work initially are not appropriate for the new products in the portfolio
• Tech Infrastructure — Tech Debt everywhere
• Leadership — Leadership that worked initially often tends to fail if you continue/forced to change their roles and behaviors
• Motivation to overcome is very strong
• Company is often in pursuit of an IPO or in pursuit of being a core business to another business
• The ability to have a positive impact on the world is very motivating.

Chapter 5 — Enterprise Companies: Consistent Product Innovation:

• For companies that succeed in scaling and want to create a lasting business
• They need to ensure consistent product innovation
• This means constantly creating new value for their customers and new value for their business
• Not just tweaking and optimizing an existing product but rather developing each product to its full potential
• Many large companies have already embarked on the failing track. They become all about leveraging the value and the brand that was created many years or even decades earlier.
• A large company can stay afloat for many years even when the end is very certain
• When companies reach IPO size. Stakeholders work hard to protect what the company has created
• Sometimes this means shutting down new initiatives and new ventures that could help recreate the business
• This potentially could put the core business at risk
• Some put so many obstacles up that to new ideas that few people are willing or able to drive the company in a new direction
• The Symptoms of this are hard to miss they entail
• Diminished morale
• Lack of innovation
• How much slower it is for new product work to get into the hands of customers
• When the company was early it likely had a clear and compelling vision. When it achieves enterprise stage the company has more than likely achieved that vision and people aren’t sure what’s next
• Product teams complain about the lack of vision and lack of empowerment the fact that it takes forever to get a decision made
• Leadership gets frustrated with the product team as well and resorts to innovation centers to spin up new ideas within the company. This rarely results in the innovation that they’re looking for

Chapter 6: The Root Causes of Failed Product Efforts

Teams have the same basic way of working all over the globe regardless of size

Everything starts with ideas (internally / externally)

Most companies put these into a roadmap, they do this because they want to work on the most important things first

Second, they want to be able to predict when things will be shipped to production

Each idea needs

1) how much money or value will it make

2) how much money or time will it cost

If Idea makes it to the top of the list

Waterfall:

PM’s talk to stakeholders to flesh out the idea

They come up with a set of requirements / they might be user stories or some form of a technical specification, their purpose is to communicate with the designers and engineers what need to be built

Once the requirements are done it hits the UX design team to flesh out the flow

Then it hits the engineers

Engineers build it

Regression testing / green light

Deploy to actual customers

Why does this introduce problems?

1. Source of ideas leads to sales-driven specials /stakeholders building products this is not the best source of ideas
2. Lack of team empowerment, the fatal flaw in business cases (you’ll never know about the business case / it depends entirely on how GOOD the solution turns out to be)
3. Product Roadmaps are a prioritized list
4. 2 Truths about product
5. At least half of our ideas are just not going to work (Customers aren’t as excited / Products can be too complex / customers would love it but it takes too many resources)
6. Even with the right potential, it takes many iterations to get the implementation of this idea to the point where it delivers the necessary business value (time to money)
7. Product management in this model is really project management it’s really gathering requirements and documenting them for engineers 180 degrees away from modern tech PM
8. Similar to the role of design (way too late in the game to get input from design)
9. Engineering gets brought in too late they say if you’re just using your engineers to code, you’re only getting about half their value (Engineers might be the best single source of innovation)
10. Principles and key benefits of Agile are getting way too late (with this model we’re getting around 20% of the agile methods, this is agile for delivery)
11. This entire process is largely project-centric. The company usually funds projects, staff projects, pushes projects through. (Projects is about output, the product is about the outcome, yes something was finally released but it doesn’t meet its objectives so what finally was the point)
12. The biggest flaw of the older process is that all the risk is at the end which means customer validation is way too late. These are not lean principles. All the cost is at the end!
13. Finally, while we’re busy doing this process and wasting time and money. We lose the opportunity cost. We can’t get that time or money back

Chapter 7: Beyond Lean & Agile

There is no silver bullet with product

Modern Agile / Best product teams

3 Core principles of lean and agile

1. Risks are taken before they build anything
2. Value risk — will customers buy it?
3. Usability risk — customers figure out how to use it?
4. Feasibility risk — can we engineer it with the skills/time/resources we currently have?
5. Business viability risk — sales/marketing / does it work for the business and legal?
6. Products are defined/designed collaboratively not sequentially
7. They have moved beyond the old model in which: The PM defines requirements -> A designer delivers on solutions that deliver on those requirements -> Engineering implements. With each person living with the constraints with the ones that precede it.
8. In strong teams engineers and product work side by side in a give and take way to come up with tech-powered solutions that customers love and are good for business

It’s all about solving problems not pushing features

1. Traditional product roadmaps are all about output
2. Strong teams know it’s not just about implementing a solution
3. They must ensure that the solution solves the underlying problem.

Chapter 8: Key Concepts Holistic Product

Holistic Product is -> functionality + technology + UX Design + how we monetize + how we attract + how we acquire + delivering the product value

If your product is an e-commerce site — this includes the merchandise fulfillment and returning experience

If it’s a media company — it’s everything except the content

You’re not just concerned with implementing features

High-level concept about the process:

There are two high-level activities in all product teams:

1. Discover the product to be built
2. Deliver that product to market

Continuous Discovery and Delivery:

Our two main activities in cross-functional product teams. Working in parallel.

Always working in parallel Designer x PM work on every day / while the engineers work to deliver production-quality product

The engineers are also helping daily on the discovery

PM and Designer are also helping daily on delivery mainly to clarify intended behavior

Product discovery -> intense collab of product management / UX Design / engineering

Tackling the risk before we write production software. Separate good ideas from the bad. The output of product development is a validated product backlog.

Will the user buy or choose to use?

Can the user figure out how to use this?

Can our engineers build this?

Can our stakeholders support this?

Prototypes:

• Product discovery involves running a series of experiments. We use prototypes instead of products.
• It requires less time and effort.
• Most companies test ideas each week on the order or 10/12 ideas each week
• The prototype is not ready for prime-time / certainly not something your company would try to sell and stand by behind
• There are all about learning fast and cheap

Product Delivery:

• The purpose of discovery and prototypes is to come up with something that provides some evidence that it is worth building and we can deliver to customers
• Build and deliver production quality technology products

Product and Product/Market Fit:

• Just because you’ve invested time and effort to make a product does not mean anyone will want to buy it
• In the product world, we strive for the product to make fit. This is the smaller actual product that meets the needs of actual customers
• Marc Andreesen is credited with popularizing this particulate concept
• They are the result of delivery

Discovery help determine the product

Delivery that actually does the work necessary to build /test / release the product

Product Vision:

Finally, Critical Concept is product vision

Usually: 2–20 years out

How the organization intends to deliver on the companies mission

Minimum Viable Product/Prototype:

MVP: Been around for many years

Popularized by the Lean Startup

Concept of MVP has caused confusion

Most teams spend months building an MVP when they could have achieved the same learning in a fraction of the time (sometimes days)

The other unhappy consequence is normally confused and embarrassed.

The MVP should be a prototype, not a product

Using the more general term prototype makes it more clear to everyone.

The prototype is for discovery

Product is for delivery