My Product Values
This list contains some of my beliefs about how products should be developed and how a team or startup should go about the business of making something great.
This was originally posted by Adam Wiggins on his Github gist. It was titled: My Heroku Values. I’ve forked it on my own gist and modified a few things here and there. By and large, this is an re-iteration of what Adam Wiggins had originally posted.
1. Make it real
Ideas are cheap. Make a prototype, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don’t say you did something, provide a link that proves it.
2. Ship it
Nothing is real until it’s being used by a real user. This doesn’t mean you make a prototype in the morning and blog about it in the evening. It means you find the people whose problem you are trying to solve for and get them to use the product. Get their feedback and iterate.
3. Focus on usefulness
Think about how this fits into the world in a macro-scale. Design systems, not features. Ask how will this be useful to people in the future? Then start building. http://irondavy.quora.com/Applied-Discovery-Presentation-from-Build-2013
4. Design everything
Be intentional. Everything has a flow. Make yours easy to follow. The experience is the product. Make yours delightful and memorable.
5. Quantity over Quality
Quality is the essence of anything good in life. But it doesn’t appear from repeating theory. Quality is the results of thousands rounds of feedback and improvement. Quantity produces quality. Shorten your loop so that you can get to quality more quickly.
6. Everything is an experiment
Anything we do — a product, a feature, a standing meeting, an email campaign — is always subject to change. Life is an experiment. Hypothesize, test and then iterate.
7. Celebrate learnings
There are no failures, only places for learning. Steps:
1. EVERYONE celebrate that fact that you were taking risks
2. Ask yourself: “What can I learn from this?” Then write it down.
3. Apply what you’ve written down and get back to work.
8. Intuition-driven balances data-driven
Hunches may guide you to create value. It’s true sometimes users don’t really know what they want. Creating products people love requires treating product development like art, not science; but products have to solve real user problems. Understanding the impact of product changes is best achieved by examining the data. Use data to make evidence-based decisions.
9. Divide and conquer
Big hard problems become easy if you cut them into small pieces. How do you eat the elephant? One bite at a time. If a problem seems hard, think about how you can cut it into two smaller, easier problems. If one of those problems is still too hard, cut it in half again.
10. Focus on simplicity
Do we really need that feature? Can we delete that code? Can we, use existing infrastructure instead of rolling our own? Can we outsource to or partner with another company so that we don’t have the build and maintain something? It’s not the code that is valuable, it’s the understanding you’ve gained from building it. See James Lindenbaum’s startup school talk. Never be afraid to throw something away and do it again, it will almost always be faster to build and much better the second (or third, or Nth) time around.
11. Results, not politics
You “get ahead” in your career by delivering real value to customers. “The best ideas have to win.” — Steve Jobs.
12. Decision-making via ownership, not consensus or authority
Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is where “the buck stops” and the owner makes the final call.
The owner should collect feedback from others, but feedback is just that: input that the owner may or may not choose to incorporate into their work. If something doesn’t have an owner, no one should be working on it or trying to make decisions about it. Before those things can happen, it has to be owned.
Apple’s term for owner is “directly responsible individual,” or DRI.
13. Do-ocracy / intrapreneurship
Ask forgiveness, not permission.
14. Gradual rollouts
Test out the message for a public launch by first sending it around internally, and later writing the private beta announcement. Collect feedback and adjust. By the time you’re ready to take it public to a wide audience, you’ll be fairly certain to have worked out all the kinks.
15. What we say / write dictates what we think / do
Clear writing is clear thinking. Think carefully about how something is named. Pick exactly one name for each concept and use it consistently.
16. Ignore the competition
“Competitors will find a way to put themselves out of business no matter what you do. You’re at risk of putting yourself out of business also, so mind your own ship.” Tony Stubblebine said it the best.
17. Strong opinions, weakly held
Have a strong opinion and argue passionately for it. But when you encounter new information, be willing to change your mind.
18. Candor
Be honest and truthful. Constructive criticism is the best kind. Avoid keeping quiet with your criticism about someone or something for the sake of politeness. Don’t say something behind someone’s back that you wouldn’t say to their face.
19. Machete design
The value of a product is the number of problems it can solve divided by the level of complexity the user needs to keep in their heads. Consider an iPhone vs. a TV remote: an iPhone can be used for countless different functions, but there’s very little to remember about how it works. With a TV remote you have to remember what every button does; the more things you can use the remote for, the more buttons it has. We want to create iPhones, not TV remotes.
Altogether, I think these 19 rules should serve as the Magna Carta for startups.
