East Beach in the dark
Highlights from ’11 Laws of Product Development’ by Sean Johnson
Highlights from ’11 Laws of Product Development’
“Wasting months of your life and thousands of dollars of other people’s money to solve a problem you’re not sure exists is insanity.”
“De-risk your problem hypothesis as soon as you can. Be rigorous about it. And be 100% honest with yourself as you receive feedback. Iterate on the problem and solution hypotheses until you’ve found something people get legitimately interested in.”
“New solutions have to either be dramatically better than the status quo, or have to completely reimagine the experience to dislodge an incumbent and carve out space.”
“Identify the 1 or 2 things your product needs to do to be better than everyone else.”
“Spend most of your energy there. Iterate on it until that functionality is world class. Only add ancillary functionality if your customers are yelling at you.”
“Treat the onboarding process as an essential part of the core experience.”
“Ideally have it assist in the user creating content or completing whatever activity maximizes their chance of adoption.”
“The first version of your product is going to be wrong.”
“Users won’t understand the value proposition, or they will but will find it too hard to sign up, or they’ll sign up but not engage further, or they’ll engage further but not convert from free to paid. Expect it. Plan for iteration.”
“One benefit of focusing on the core experience is it can speed up your time through the Build-Measure-Learn loop.”
“All other things being equal, the company that can iterate on their product in response to customer feedback the fastest will usually win.”
“Have a plan for engaging with your early customers throughout their journey. Make sure you know exactly what they do, what they think, what they like and what they don’t.”
“Product teams should be aggressively iterating on their product until P-M fit is achieved.”
What if driving followed Modern Agile principles?
How might driving on UK roads look if everyone was applying Modern Agile principles to their driving?
Make people awesome
Everyone wants to get where they’re going. If driving was Agile, and all drivers were trying to make each other awesome, there would be more cooperative driving where everyone has as their aim helping everyone get where they’re going, rather than focusing on where they want to go ahead of all the other drivers. Everyone would arrive where they wanted to go feeling less stressed and more awesome from helping others get where they wanted to go.
Make safety a prerequisite
Everyone wants to be stay alive. If everyone made safety a prerequisite of driving, everyone would always wear a seat belt, not use mobile phones, or drink and drive, and keep sufficient stopping distance between them and the car in front. Everyone, drivers, cyclists, and pedestrians, would be treated with more respect, feel more respect, and be much safer.
Experiment and learn rapidly
Everyone wants the best experience. If everyone experimented with what routes they take, what time they travel, what music they listen to, what they wear whilst driving, etc., etc. they could improve their experience of driving. Everyone would drive less on habit and learn different ways to improve their experience of driving.
Deliver value continuously
Everyone gets more out of driving than just getting somewhere. If everyone who valued fuel economy knew how to drive efficiently they would receive continuous value in reduced fuel costs, and there would be environmental value too. If everyone who valued nice scenery over shorter journeys took more scenic routes, they would receive their value in seeing different landscapes and add value to the drivers who want shorter journey times by avoiding more direct routes. Different values can be delivered continuously and concurrently.
This quick thought experiment taught me two things; Modern Agile principles could be applied to almost any set of circumstances where human beings are doing some kind of shared activity, and, in order to actually work, all those people need to be able to communicate and agree to use all the principles.
Highlights from “Observations on Product Management” by Dan Hill
Highlights from “Observations on Product Management”
” The job of Product Management is to deliver good products to end users. The sheer number of possible definitions of good, product and user mean there’s no standard look to a Product Manager. But if you don’t deliver, the product is not good, or no-one uses it, you’ve done it wrong.”
” There’s good process and bad process. Good process is any that allows the team to produce better work faster, with joy and elegance. Bad process is anything else.”
” Incremental development and vision are not orthogonal; they both require the other. All product must start with a vision — a point of view — but then be built critically step by step. It’s ok to learn something new as you go.”
Exploring modern agile principles: Make people awesome
As my interest in Modern Agile grows I’ve been looking for situations at work from which I can learn about how to apply the principles and how to work in a way that makes people awesome.
There is a project team (who aren’t Agile) who seem to have a culture of focusing only on what they need. They don’t seem to be able to hear the needs of anyone else from any of the other teams they work with. I can see how this culture can develop in a team that is so completely focused on hitting deadlines and not having any part of the project slip beyond its allotted schedule, and I can see how this culture is the opposite of the Modern Agile principle of making people awesome. In this situation, the people that work with that project team don’t feel awesome because they aren’t listened to, and are given the message that the project team are able to command their time and effort without being able to feedback on whether they are focusing on the right things at the right time. And I doubt that the project team feel awesome as they probably feel like getting anything done is a struggle against the people who are supposed to be supporting them on the project (of course, they don’t recognise that those people have other work to do outside of the project because they are so focused on their project).
I’m not going to try to suggest a solution to this problem as I don’t think the situation/culture will change, but I definitely want to learn from it. So, I’m going to try to:
– Communicate more clearly,
– ask questions to encourage discussion,
– remember that other people have their own priorities,
– actively listen for implied meaning and ask follow-up questions,
– ask what they need to be successful,
– allow open honest conversations,
– and encourage everyone to be able to positively challenge what anyone says.
I hope that if these practices become part of the projects I’m involved with then we can all help to make each other awesome.
Technological leap frogging
I heard a programme on BBC Radio 4 about a business supplying small solar power packs to the people of small villages in rural Africa.
These villages have no electricity infrastructure, and batteries and kerosene are expensive, so households purchase a solar power pack, which they pay for over eighteen months. This empowers the villagers to electrify the village without having to wait for the government to build national grid – type infrastructure which is cost prohibitive anyway.
This is a great example of how technology can be used for revolution rather than relying on evolution as we often do in developed countries. Mobile phones are another great example. They leap frogged land line technology and went straight to mobile technology, which meets their use case better.
I wonder how this approach of leap frogging could be used on small scales to deliver products that meet customers use cases but ignore the accepted best practice of iterative development. Does it rely on the evolution to have happened elsewhere? Does it need to follow a distributed model; be very localised and empowering of the users with minimal support from a larger authority?
Disruption eventually gets disrupted and consumed by the establishment
Uber is held up as an example of of how to disrupt an entire industry, in this case the taxi industry. But sooner or later disruptive ways of doing things butt horns with the establishment. Industries like taxis are regulated by the government, the government makes the laws, and the government doesn’t like it when those laws aren’t adhered to. That’s when companies like Uber find their ‘disruptive’ ways such as not considering their drivers employees challenged and disrupted by the establishment, which decides that those drivers are employees. In this way the establishment takes away any disruptive advantage, and eventually consumes the disrupted into the mainstream of the industry.
The government’s own digital team proved this when they looked at ways to disrupt and digitise the process of buying road tax. They were faced by a law that prevented what they wanted to do. Of course, the solution was to change the law, which they did, but something disruptive companies can’t do.
Crypto-currency, the application of block-chain technology to financial transactions, will go through the same cycle. It’s still too new a technology to have developed a useful application, but it will. And when a disruptive company comes along that can commercialise that application successfully they will be eventually be faced with a government that says ‘play by the rules or don’t play at all’. This is the cycle of innovation in regulated industries. It starts with the birth of the technology, then the application of the tech to disrupt an industry, then the legal challenge by the establishment, and finally the disbandment or consumption of the industry.