Book summary: “ Inspired: How To Create Tech Products Customers Love” — Part 4.2

Note: If you are truly looking for some valuable resources to learn and understand about modern product management, then I strongly recommend you to read this book twice. Buy link — here.

Part 4.2 : The Right Process

In the last blog, we discussed Product discovery techniques and it’s techniques, Discovery framing techniques, Discovery Planning techniques, and Product ideation techniques. Now, we can discuss the

Discovery prototyping Techniques:

Prototypes of various forms have been around for as long as we’ve been applying technology to solve problems. Per the famous Fred Brooks quote,

“Plan to throw one away; you will, anyhow.”

Principles of the prototype:

1. Purpose — To learn something at a much lower cost in terms of effort and time than building out a product.
2. Key benefits- To force you to think through a problem at a substantially deeper level than if we just talk about it or write something down.
3. Prototyping is a powerful tool for team collaboration. Members of the product team and business partners can experience the prototype to develop a shared understanding.
4. Fidelity refers to how realistic the prototype looks. Most of the time, Low fidelity makes more sense as it’s fast and cheap when compared to high fidelity.
5. The primary purpose is to tackle one or more product risks in discovery. However, often it goes to the second benefit, which is to communicate the engineers and partner on what needs to be built. Also referred to as Prototype as a spec.

Major classes of the prototype

1) Feasibility prototype

• These are written by Engineers to address the technical feasibility risks during product discovery.
• The idea is to write just enough code to mitigate the feasibility risk.
• Few examples: New technology or new algorithms, performance, or scalability concerns.

2) User Prototype

• A user prototype is key to several types of validation and is also one of our most important communication tools.
• Low fidelity User prototypes — doesn’t look real but essentially an interactive wireframe. Often represent one dimension of the product — the information and the workflow.
• High fidelity user prototypes — Real simulation of look N feel of the product. The data or the information you see is very realistic. More meaningful version.

3) Live — data prototype:

• Live- data prototype is a very limited implementation. It typically has none of the productization that’s normally required, such as the full set of use cases, automated tests, full analytics instrumentation, internationalization and localization, performance and scalability, SEO work, and so forth.
• The key is to be able to send some limited traffic and collect analytics on how this live-data prototype is being used.
• Limitations:
  - This is code, so engineers must create it. not the designers.
  - This is not a commercially shippable product and it’s not ready for primetime.

4) Hybrid Prototype:

• Also referred to as the Wizard of Oz prototype.
• Wizard of Oz prototype combines the front-end user experience of a high-fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation.

Transformation Techniques:

As a very explicit example, moving from mercenary-style, product roadmap-driven, output-focused teams, to truly empowered, accountable product teams that are measured by business results represents a major cultural shift and a substantial handoff of power and control from management to the individuals on the teams.

1. Discovery Sprint technique:

• A discovery sprint is a one-week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing.
• A discovery sprint is definitely useful for more than just transformation. It could just as easily be considered a discovery planning technique or a discovery prototyping technique. But I find it’s most helpful in bringing all these things together, so I choose to include it here.
• Some people use the term design sprint rather than discovery sprint, but as the purpose of the work — when done well — goes significantly beyond design.

2. Pilot Team technique:

Some people in your organization love change, some want to see someone else use it successfully first, some need more time to digest changes, and a few hate change and will only change if they’re forced to do it.

• Pilot teams allow the rollout of change to a limited part of the organization before implementing it more broadly. The idea is that you look for a product team to volunteer to try out some new techniques.
• You let them run for a while (usually a quarter or two) with this new way of working and see how this goes.

3. Weaning an Organization off Roadmaps:

• The goal is that over time, the organization moves its focus from specific features launching on specific dates to business results.
• For this to work, it’s important to acknowledge the two big reasons why stakeholders especially are so attracted to roadmaps:
• They want some visibility into what you are working on and assurance that you are working on the most important items.
• They want to be able to plan the business and need to know when critical things will happen.

Process @ Scale

Managing Stakeholders:

Who is a Stakeholder?
This group of people typically includes:

1. The executive team (CEO and leaders of marketing, sales, and technology
2. Business partners (to make sure the product and the business are aligned)
3. Finance (to make sure the product fits within the financial parameters and model of the company)
4. Legal (to make sure that what you propose is defensible)
5. Compliance (to make sure what you propose complies with any relevant standards or policies)
6. Business development (to make sure what you propose does not violate any existing contracts or relationships)

In terms of the stakeholders, the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.

Communicating Product learnings:

The update is meant to address several purposes, some tactical and some cultural:

1. The big learnings are important to share broadly, especially when things don’t go as hoped. As a side benefit, sometimes someone in the audience has an insight about what might explain the results.
2. This is a useful and easy way for the various product teams to keep apprised of what other teams are learning, as well as ensuring that useful learnings make it to the leaders.
3. This technique encourages the product teams to keep their focus on big learnings and not on minor experimentation that doesn’t have a real customer or business impact one way or the other.
4. Culturally, the organization must understand that discovery and innovation are about continuously running these rapid experiments and learning from the results.
5. It is also important culturally that the product organization be transparent and generous in what they learn and how they work. It helps the broader organization to understand that the product organization is not there “to serve the business” but, rather, to solve problems for our customers in ways that work for our business.

Disclaimer: At many places, I’ve used the exact phrases from the book to capture the 100% nuances of the information.

If you enjoyed 👌 this story, please click the 👏 button and share it to help others find it! Feel free to leave a comment below ✋.

The next blog will the final read for the Inspired where we discuss more Right culture. Stay tuned ❗️⭐️