Table of Contents
If a product is only as good as its feedback loops, then only the feedback of the customer matters. There will be many stakeholders, but only the customer’s opinion counts. A natural extension should be we only listen to customers. But as Steve Jobs showed us, the customer doesn’t always know what they want.
Building Feedback loops
As such, there are two ways to build feedback loops. First is through the intuitive feel of a product visionary–typically a Founder or through the rigor enforced by a disciplined leader. A good product is a combination of both vision and discipline. The vision ensures there is healthy first-principles thinking, and the process rigor ensures focus.
Big picture thinking while obsessing over small details is hard. Few companies do it well, and those who do, end up having multi-billion dollar valuations. The only way to know if you’re in that universe is to be thoughtful about the process used to build what the people want.
Acknowledge the Myth
First, stop saying the product sells itself. Nothing in life sells itself. As easy it is to sell cheese to a toddler, it too requires a selling process. The product that sells itself is a myth—a charlatan’s tale at worst, a newbie’s naivety at best.
Take product marketing as an example.
In an ideal world, the product and the product’s marketing are indistinguishable. As Malcolm Gladwell observes, only late-night infomercials succeed at this consistently. For the rest of us, thinking through every piece of content, how the customer will read it, and how the algorithm that controls what the customer reads will display it is everyday, relentless, non-glamorous hard work. Only the results matter and no points given for effort.
In Awe of the Wow Effect
All products must always strive to deliver the wow effect. The wow effect is the point in the app flow when the customer gets the epiphany that this is the product for them. The sooner it is delivered, the more likely the customer is going to be a lifetime fan. The better you get at this, the more your competition will be in awe of your product and your product-building prowess.
Back to feedback loops.
Feedback Loop Anti Pattern
Dysfunctional feedback loops create mediocre products. In the absence of a clear feedback loop to vision, The “why to build” devolves into a damn-the-torpedoes gut instinct, or the highest-paid person in the room being the visionary. Personal opinions masquerade as first-principles thinking in an echo chamber where no one wants to tell the emperor the truth. The best leaders build a feedback loop of iconoclastic debates that move the organization forward.
The other anti-pattern happens at the process level and because of the absence of a coherent vision. The lack of a crisp vision means everyone is looking for data to make simple decisions. Data becomes a crutch, and waiting for statistical significance becomes the go-to explanation for the lack of product velocity.
The fact is that not all product decisions need A/B tests. Some need common sense, an intuitive view of the customer’s need. Some decisions you cannot know without testing the thesis rigorously. Kayak.com A/B tests its pricing page every 15 minutes. However, having an iOS or Android app is a strategic call that should require no market research.
Hooked on Robust Feedback
The Hooked Model has been the best way I’ve found to build robust product feedback loops. Its focus on the core completing action makes sure that any instinctive big bets or A/B testing are grounded on reinforcing the action.
Every interaction is an opportunity to improve engagement, increase investment in your product. The Hook model ensures you don’t lose sight of that.
This focus ensures that a password reset email is not just an email with a code but a link to the exact point on the application where you need to go next. This focus also shows up when sending an order update text message. Instead of giving an order update about a nonsensical order id, send it with a link that’s customized to the recipient.
What follows are the few lessons learned from implementing the model in several organizations.
Lesson 1: Frequency v. Salience
Frequency and Salience aren’t in the book, but Nir shared on one of our 1:1 calls. After you’ve tabulated all your use cases along the trigger, action, reward, investment columns, then sort them via frequency and Salience. The use cases that score the highest win. When there’s a tie, frequency wins.
Lesson 2: Watch Month 0 and Month 3 Inflection Points
Every product has a Month 0 and a Month 3 drop-off—points during its usage, where a user cohort has the most significant drop-off. The longer the product has been around, you find the small improvements work best. Earlier in the life cycle, features rule the roost. If you are early in the life-cycle, say trying to get your first 100 customers, see if you can get those 100 customers to stay for the first 30 days, and then for the first 90 days. This will ensure that while you’re always chasing the wow effect, there is a specific goal in mind.
Pay yourself to use the product works even if the product is pre-revenue. For example, if your product is priced at $29.99/month, pay yourself $29.99 every month and see if you would continue doing so for three more months. Would you continue doing it for 12 more months? If the answer is no, then you have work to do.
Lesson 3: Speed is your Ally
The Hooked model prizes speed both on what’s developed and how it’s developed. If the focus is to increase the core completing action, then the features that increase that metric get prioritized. The focus is to create a tight user flow that gets them to the wow moment quicker. When combined with an agile developing process, you find yourself building a product optimized for growth and growth alone. All other crud is unnecessary and goes to the backlog.
Lesson 4: People build Products
A process is only as good as the people who drive it. The Hook model is no different. The best implementations were where the Founder (playing the Product Owner role), the technical leads, and the software engineers got the model, what it was driving, and then coalesced around that goal. It is a truism, but there is no substitute for teamwork.
Finally
If this were a listicle, an alternate title would be The Four Lessons Learned when using Nir Eyal’s Hook Model. Other models have similar flywheel characteristics, but this is the one that has me hooked and why it is my most gifted book to anyone building a new product.
