Taking a Moonshot

I shared a few takeaways on IT projects in the recent Reid Hoffman post and I’ve just come across some more gems in a post by Astro Teller, the guy who runs the Google[x] group. Here they are:

Speaking of self-driving cars,

But this real-world testing taught us something that steered us off that path we’d been on… Expecting a person to be a reliable backup for the system was a fallacy. Once people trust the system, they trust it… We came quickly to the conclusion that we needed to make it clear to ourselves that the human was not a reliable backup  —  the car had to always be able to handle the situation. And the best way to make that clear was to design a car with no steering wheel 

Decisions like this act as a catalyst to move beyond the design phase of a project. Doing something extreme will draw out objections that allow you to validate your requirements and design and these objections show how people intend to use the system, how much they’re prepared to trust the system and and what would need to change to deepen that trust. It’s valuable to be explicit about your assumptions and to be prepared to take your assumptions to their logical end. If you do that, you’ll often find that you can simplify your design, shed some historical baggage, and produce a product that better fits the requirements.

On the psychology (and value) of end-user feedback

The faster you can get your ideas in contact with the real world, the faster you can discover what is broken with your idea. Seeking out contact with the real world means hearing and seeing things you don’t want to hear and see  —  because they’re discouraging and disheartening when you’re pouring your all into something. But better to learn that after a few days then after a few months. The more work you do before you get the learning, the more painful the learning will be, and the more you’ll unconsciously avoid those learning moments.

My first reaction to this quote was to start justifying why I should keep my products closed until they’re finished (enough). Keeping them closed means that nobody has a chance to second guess me, or try to change the scope. Now, managing a stream of requests while you’re trying to actually deliver something is a challenge but as long as you can maintain focus, and see feedback in the context of the bigger picture and if the act of sharing doesn’t consume much time, opening up the product will be valuable.

Sharing and honestly seeking feedback makes you vulnerable. Allowing yourself to become vulnerable is hard. We (developers, ops engineers, product managers, designers etc) are in the business of creating, and creating is a personal thing and few people enjoy giving others an chance to not like something they’ve created. It’s easy to get offended when someone gives feedback, but we can’t afford to if we’re truly going to be effective in producing a product that actually helps others.

Here’s the full article, How to Make Moonshots - it’s an interesting 10-15 minute read.