Some unconventional thoughts — Inspired by “Working Backwards” (Part 1)
…Because book summaries and reviews are all widely available and accessible on the internet. Furthermore, some parts are out of my current know-how and experience, leading to shallow comprehension 😛 I want to interpret the book and write about it, personally. From my own perspectives and my own experiences.
First and foremost, this one is proudly inspired by the original book: Working Backwards by Colin Bryar and Bill Carr. And the podcast In Depth by First Round’s really deepened my understanding. Please check it out and give them an endorsement if you feel like it:
- The book: https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595. Also, I will post my book review on Goodreads, and update the link when it’s on air.
- The Podcast:
My writing consists of 4 points of view (possibly be added some more), divided equally into 2 parts. This is the first part, delivering 2 points of view:
#1. When agility drives innovations off track
#2. When (unfair) advantages become barriers
#1. When agility drives innovations off track
In terms of speed and flexibility, Agile methodology owns its name for the quickly adaptive cycle of product development. It’s suitable for testing the market demand, shortening time to market, and improving the product frequently. I’m not going to talk about how obviously helpful it is.
Just about when it’s not at its best place. Suppose that the market demand is well-understood. Your customers need a complicated and well-developed invention. Anything less than it is not the wanted product.
Dealing with this sort of situation, enforcing your team to quickly release so-called MVPs can be even more problematic:
- Testing MVPs is way too costly and irrelevant to demonstrate how the wanted product is needed and/or which feature of the wanted product is needed in particular;
- Building MVPs doesn’t make it easier to build the wanted product than to start from scratch.
The situation often happens when you aim at inventing the new (even disruptive) solution for the old/classic/well-known problem with high complexity. It requires:
- Envisioning innovation: Why you should invent something new at all, while alternatives/substitutes are currently available? How the invention brings value to the customer? How the product will/should be at its end-game state?
- Planning for innovation: Since the wanted product is complicated and massive to build, and you’re probably not able to get it done completely at the first attempt. So the existential decision to make, in terms of prioritization, is: What to do — in which order — with which level of completeness, so that partial development must be constructing, instead of destructing, what you’ve envisioned as a whole in 1.
These 2 tasks above take time with deep and thorough thoughts. Rushing for quick deliverables at the early phase leads to unavoidable trade-offs: Low quality AND/OR non-expandable and unscalable products. That is costly all the way. Worst: Once this false development is repetitive, the cost will be raised on a loop along the way. It seems impossible for the “end game state” to happen.
— To Amazon, when they clearly knew the value they wanted to create for the customer in the early concept of AWS, they spent 18 months thinking about the crystal clear vision and design value proposition before the 1st line of code was written. “Many companies think you have to go fast to go fast, but Amazon went slow to go fast.”
“More so than most companies, Amazon thinks about creating value for customers, focusing specifically on how they can create unique and distinct products. Many companies get tripped up and think about innovation as something where they need to come up with ideas, quickly get them out and test them, in the sort of agile method of iterating quickly,”
— Bill Carr.“Moving fast isn’t about moving quickly, throwing stuff over the fence, or launching it in an app to see how it sticks. Stopping to think about the value you’re trying to create for the customer and the problem you’re trying to solve is essential, especially when you’re moving into a brand-new area”
— Colin Bryar
#2. When your (unfair) advantages become barriers
I know the heading sounds counter-intuitive. But that happens.
Disclaimer: The terminology used below is particularly defined for this blog.
When it comes to advantages
They are what you EARN while other competitors don’t. The barriers are not from the advantages themselves, but from the way you think about it. When you have to choose what to do, the advantage-based approach will narrow your choices. Because there are many more kinds of stuff that you are not currently equipped to do, but still worth giving your best shot to make it.
— For Amazon, it exists with the concept: “brainstorm around customer needs, not ability”. A classic example is when they came up with the idea of Kindle. By that time, they’d had ZERO ability to develop hard devices. A ton of complicated capacity: Engineering, Supply Chain Management, Manufacturing,… were none of Amazon’s advantages.
We had never built a hardware device as a company. We sold tons of electronics as an e-commerce retailer, but we certainly had no capability to build one. And I remember questioning our wisdom at one point, like why on earth would we go build our own device? But instead of taking a skills-forward approach, we said ‘What would be the product that, if we could create it, customers would love it?” — Bill Carr
When it comes to unfair advantages
They are what you are GIVEN (that’s why it’s called unfair) to be (absolutely) superior to your competitors. The barriers come when you have to pay the price for these unfair advantages. The more you are given, the more you must care about the giver(s), the more you’re not allowed to do. Once doing business together, benefits — in their all form existence, are always traded equally. No free lunch.
Building your product, together with running the business, is extremely tough itself, to anyone. Getting this work done while balancing mutual benefit for (multiple) giver(s) is much tougher. Sometimes, you have to sacrifice what you earn and/or what you should do for what you’re given. Sometimes, you have zero bargaining power. Sometimes, negotiation is impossible.
Everything comes with a price. Unfair advantages are no exceptions.
The next blog will cover 2 points of view: #3. On leadership and #4. Data Analytics. Please don’t mind the latency.
Until next time,
Quyen.
