Mic Product Team Principles
Our team relies on pithy principles to keep our work on track — so pithy in fact that we figured it’d be a good idea to write out the thinking behind them.
We each picked one of our principles and explained why we believe in it.
Make something people want
This is taken from Y Combinator, via Paul Graham. It’s a simple but powerful phrase. As a product team, our input is a problem and our output is a solution. At a fast-moving startup, with never enough resources, we must always be solving a problem that users actually have. The worst feeling is shipping something that no one cares about. Ship something people want.
A problem well-stated is half-solved
Sometimes a team is midway through a project, and members are wondering about the context and background story of their work. If a team can’t answer every question about the origins and purpose of a project, they don’t truly understand what they’re building. “A problem well-stated is a problem half-solved” holds us accountable: it requires us to ask hard-hitting questions to cut through the noise to get to the core problem. As Albert Einstein said, “If you can’t explain it simply, you don’t understand it well enough.” If we can very easily explain a problem, we understand exactly what it is, which brings us that much closer to finding the solution.
Single source of truth
When you’re working in a big group, things are liable to get messy. Everybody has a unique role, a unique perspective, a unique vision; keep everybody on the same page by literally creating that page (or Google doc, or presentation, or set of designs) and sticking to it. Make sure everybody has access and everybody signs off on changes, and watch your conflicts, confusions, and potential for duplicated work disappear. One source of truth: zero sources of headache™.
Ask the user
We must fight the tendency to rely on intuition and gut feeling when iterating on our products. We may be advocates for our users, but our experiences as engineers, product managers, and designers have given us unique viewpoints that may not reflect the opinions and desires of our users as well as we think. We can make better decisions when we utilize user feedback in the form of usability testing and data analysis. Our fans are out there in the world using our product, and ready to give feedback. All we have to do is ask.
Give reasons, not opinions
It’s easy to say, “I like it” or, “I don’t like it” when reviewing any new feature. We should make an effort to refrain from saying this. Remember whom we are creating products for, and leave “I” out of our thinking around our products. Frame your feedback in this way: “Because of XYZ reason, this feature will or will not deliver on [KPI].” Evaluating ideas in this mindset will guide our process to create better products for the user.
Discussion, discussion, discussion
Everyday we have new, fresh and vibrant ideas for our users. Often, our initial idea isn’t what makes it to on the site. By having discussions, we’re able to expand on our ideas. Transforming and molding them to what eventually makes it into production.
It’s not not your job
The phrase comes from Genius’s ISMs. For us this means we’re all responsible for helping each other create the very best product we can. If you see a better and more efficient way to reach a goal, tell someone. If you see something that’s broken, don’t assume someone else will take care of it. You don’t necessarily need to fix everything yourself, just trust that you have good thoughts to bring to the table. Make sure to voice your concerns and ideas, no matter the subject, so the team can benefit from your perspective.
Get feedback at 5%, not 95%
If there’s a fatal flaw in your plan, you want to find it out early, because that will save you time. Moreover it’s often easier for people to give you feedback when you haven’t done the thing yet. Help yourself out by asking for feedback when you’re 5% done rather than 95% done.
Have a retro
Having a retro means constantly learning and iterating. Not all projects are made equal. Each one is a chance to identify issues as well as celebrate the parts of the process that were successful. Taking the time to have a discussion is a valuable part of our continuous process improvement.
