Designing for distribution with Eric+Eric (YC 2011, Mochi Media)
One important question that comes up all the time is, what makes a product easy to market? I had a fun chat about the topic with Eric Florenzano and Eric Maguire who worked together at Mochi Media with my sister Ada. They also recently did YCombinator.
After the chat, eflo wrote up a helpful summary of some of the ideas we covered. I wanted to quickly share them with some comments:
1. Come up with one resounding use case–one thesis for how people should use the product. Preferably this fits in with something that users already do and already understand.
I’m going to write a ton about this later, but basically having a product in a category that people really understand makes it easier to get people through flows and to ask them to do different account setup steps. This is especially true in cases where it’s totally obvious that they need to invite friends part of a setup (communication, publishing, etc.)
2. Make sure that people entering the flow are going through one funnel, and only one funnel, and make sure all users go through it. Then tune this funnel, by doing lots and lots of tests often.
Additionally, a simple user flow means a simpler product, and because it takes so long to optimize a funnel (weeks and possibly months), you want to put all your weight behind one onboarding experience.
3. Prefer one distribution channel over a choice of many. (Just choose Facebook, or just choose Twitter.)
Similar point- make it easy to optimize. You can always add more later, but early on, quality of your funnel beats quantity of funnels.
4. Think about the channel and its context and try to match that to the expected audience. Address book scraping will pull in personal friends, Twitter broadcasting will pull in less personal friends.
It’s always funny how people think adding a Like button or a Tweet This button will suddenly make their product viral. That’s just completely bolt-on, and doesn’t make sense. Instead, you have to match the context so that the entire UX is really cohesive and it makes sense why you’re inviting people.
5. Distribution mechanisms should be universalizable. i.e. if off-site embedding is going to be the distribution mechanism, make it a core part of the product and show it to virtually every user. YouTube was given as an example of this.
Similar point re: the tendency to “bolt on” virality at the end- if you have a viral loop that doesn’t actually cohesively fit into your product, you end up with a really disjointed experience. Instead, the thinking has to start at the beginning- pick something where the sharing/invites are embedded into the idea in the first place.
6. Metrics can’t drive everything. You need to have a thesis and use metrics to validate that thesis.
Painfully learned 
7. It’s not always about tightening the viral loop at all costs–sometimes adding a step can actually improve conversions because it makes more sense. (Twitter was the example here.)
Essentially, adding more steps can add to the cohesiveness of the UX, which then improves overall conversion rate, which then helps your virality.
Anyway, those were the rough notes- I could expand a lot on this but that will have to be for a different day!
Like this post?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.
2011 Blogging Roadmap: “Zero to product/market fit”
I’m going to try to start blogging again!
It’s been a long time since I was in a good blogging rhythm, and I’m going to try to start doing it again In preparation for this, I put together an outline of an output-driven set of milestones around product, that takes you from zero to a P/M fit product thats ready to scale on marketing/tech/etc.
As far as I can tell, this is all standard fare for companies in Silicon Valley. My desire to write these posts is ultimately about documenting what’s working for people and spreading the knowledge beyond Palo Alto, CA All of these topics are ultimately derived by both my own projects as well as my advisory roles at venture-backed startups. (Some of these are listed here)
If you like the outline and want to stay up to date, just subscribe and follow me on Twitter.
Without further ado, here’s the outline- I hope to write at least a post or two per week:
Blogging roadmap goals
- “output-driven” roadmap for going from zero to product/market fit
- for small hackerish teams building consumer internet products
- the intention is to create a scalable startup that is going after a huge market, and generate huge returns for venture capital investors
- goal is to get to P/M fit in shortest time possible, defer everything else
- defers monetization
- defers marketing
- defers scaling
- (this is all by design)
- P/M fit takes a non-deterministic amount of time to get there, insanely hard, you’ll probably fail anyway
- the problem is 90% contextual, make up your own rules as you go
Concept prototype
Picking a product and market
- build for yourself (start with intuition)
- have a long-term vision
- base it off something that’s already big and already working
- big makes it easy to test and collect feedback
- already working means you have a good sense for minimum product
- also, there’s pre-existing distribution channels as well
- figure out the options for competitive differentiation – this is the core design intention
- talk to a lot of users, do a lot of research, compare a lot of products in the space
- dimensions for competitive differentiation
- competitive dimensions
- vertical audience
- design intention
- cheaper/niche
- targeting rejectors
- validating that there’s LOTS of pre-existing “pull” for the market
- search keywords
- app leaderboards
- ideal goal: simple product with fundamentally different core design intention for large pre-existing market
- bonus points for baked-in distribution, monetization, etc. but don’t let this lead the idea!!!
- usually one killer feature (not a bunch of features)
- prototype: Landing page
- what’s a good landing page experiment?
- headlines, copywriting, hero shot, etc.
- unique URLs
- anti-patterns:
- “someone’s already done this” (desire for originality)
- monetization/strategy-driven product ideas
- technology in search of a market
- “Wall Street” markets
- lumping yourself into an aspirational market
- comprehensive featureset done poorly
Paper/Wireframe prototype
Designing the initial product
- go for the minimum desirable product
- might work
- the central design intention drives the product design
- supports only the core use case, as minimum as possible
- core UX should be 2-3 pages
- limited functionality, done well. “Less but better”
- Should build bare bone prototype in less than 2 weeks (really!)
- flow-based product design
- user quotes, then fill in with UI
- might work
- low-fidelity prototyping tools
- easier and cheaper to make changes
- fix defects earlier (Toyota lean manufacturing model)
- engineers always want to prototype in code, but then sunk-cost fallacy
- get feedback from people and iterate
- prototype: Core user flows, mocked up and ready to build
- anti-patterns:
- “database-up” design
- feature creep and low product self-esteem (v1 should look like a feature!)
- comprehensive featureset all of it done poorly
- lots of pet features that don’t fit into the core design intention
Code prototype
Coding the initial product
- build the prototype as fast as possible
- fill in any blanks left out of the prototype
- use the product yourself, iterate on it while keeping with the core design intention
- focus on key flows and prioritize over ancillary ones
- don’t worry about corner cases
- get it ready to be used by other people
- prototype: Live product, usable by other people
- anti-patterns:
- taking too long
- losing focus of the central design intention
- not adjusting based on intuition and usage
- overarchitecting, trying to make it scalable or modular or future-proofing in general
Friends and family alpha testing
- private beta goals
- clean up core experience
- make product usable over multiple visits
- validate the core design intention
- not scalable
- recruiting friends and family
- focus on retention
- are users coming back?
- recruiting random people
- Find people from the existing market, rejectors, and outside the market
- Learn from extreme users
- Craigslist
- Usertesting
- user testing
- do they get it?
- how would you describe this to a friend?
- usability – remove the friction
- would they switch? (for existing market users)
- Net promotor score
- interpreting user feedback and learning to say “no”
- which users fall into the target market? Hear them out
- which users don’t? It’s OK (and maybe even good!) to have them reject
- try not to add new features unless absolutely necessary
- what features can you remove that aren’t part of the core?
- prototype: Simple product, polished by real use
- anti-patterns
- Delusion- it’s not working but you think it is
- Melancholy from user testing
- Adding features without interpreting
- Adding features that violate core design intention
- Listening to out-of-market users
- is it working?
- people understand the product
- some subset of your users like it and use it
- you like it
Random people beta testing
- traffic testing goals
- start polishing your onboarding flow
- develop options for distribution
- build some basic stats infrastructure
- not meant to be scalable
- User acquisition tactics
- ads
- PR + launch page + slow stream
- partnerships
- power through it
- Collecting feedback
- surveys
- help and problems
- recruit users to talk to
- prototype: Spreadsheet for signup flow, more polished signup flow
- is it working?
- signups are happening
- people are going through the core flow
- retention/recurring usage from target users
- product still works for you, and your friends/family
User flow optimization
- model your usage and figure out your core drivers
- this is completely product specific
- two examples- daily deal versus a chat site
- whats your “metric of love?”
- prototype your funnel – explore!
- flow chart
- excel
- SQL
- formalize/finalize with dashboards
- identify major bottlenecks for why the product’s not working
- start at the beginning of the flow
- fix bottlenecks with A/B tests
- is it working?
- how do the metrics compare to the usage model?
- 10% signup
- +1 day retention and +1 week retention
- DAU/MAU
- anti-patterns:
- trying to fix problems in core UX when signup is the problem
- over-architecting stats infrastructure
- trying to use a generic analytics product to answer situational questions
Ready to scale?
- Hopefully the major checkboxes are checked – at this point you’d have:
- Huge market
- Differentiated product
- Product makes sense to normal people
- Product is working for IRL people
- Product is working for non-IRL people
- Well-understood and optimized user flows
- Ready to scale up
- Non-scaleable marketing, tech, and otherwise- that’s fine
- Now scale everything else
Crisis, terror, and melancholy
- Is it good enough?
- Nobody likes my product!
- My product is a mess!
- It’s taking too long!
- Investors hate my product!
- I’m iterating in circles!
- When to work on a completely new idea?
- Iterations are getting diminishing returns and people still don’t love the product
Final note: Thanks to my friends who helped review and add to this: Vinnie at Yipit, Alex at Penzu, Rob Fitzpatrick, Kevin at Hyperink, Jamie/Justin at Mocospace, Ada/Sachin at Connected, Noah at Appsumo, Jason at Kima, and the other folks who helped
Like this post?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.
Metrics Driven Design slides from SXSW, by Joshua Porter
Joshua’s slides on Metrics-Driven Design got tweeted out during SXSW and I wanted to share them.
In general, I think all of the various MVP/customer-development oriented startups out there are struggling with how to incorporate design into their product process. And at the same time, more designery teams are trying to figure out how to get more agile. It’s hard. As someone smarter than me has observed, the vast majority of the MVP-oriented companies end up with pretty uninspired, incoherent products- and they don’t seem to get any better over time. So I think it’s a great challenge for the whole community to get more informed about design and figure out how to really make it work.
Great Google color-testing followup
In particular, in the first few slides there’s a really funny followup to Doug Bowman’s complaints about Google testing shades of blue. These slides claim that in fact, the color choice really did matter, and quite a bit so, and quotes Bing search guy saying that the decision was actually worth $80M. I suppose in retrospect it’s not surprising, because the bluer something is, the more it looks like a link- so given the visual signal, it is meaningful for users over billions of searches.
Metrics-informed versus metrics-driven
All that said, I do have to say that I much prefer the term “metrics-INFORMED design” rather than “metrics-driven.” You should really be driven based on your vision of the product and where you want it to go, not the metrics that you use to validate or learn about your vision. (I first read the distinction of being data-informed over data-driven in a talk by some Facebook product folks, and have much preferred it ever since – this topic probably deserves an entire post by itself).
Finally, the slides
Anyway, the Joshua’s slides are excellent and I’d encourage you to flip through them. The official place to read the details around this presentation is here, on his site. His Twitter is here.
Like this post?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.
