What cool new products are you using?
We all ask this question. It’s a common conversation starter, especially in the startup community. I’m particularly fond of this topic—I enjoy geeking out about products, writing design deconstructions, and swapping discoveries with smart folks. But these conversations provide more than just entertainment value: They are also a great learning opportunity. Understanding the subtleties of good and bad products is critical for product builders. As Paul Buchheit says, you must “live in the future" to shape it. Playing with early, innovative products can provide a competitive advantage.
This was the basis for Product Hunt. Here’s how we prototyped it.
The Idea In Its Simplest Form
The concept was simple: to build a community for product people to share, discover, and discuss new and interesting products. But when I came up with the idea, I lamented the amount of work needed to build a first version of Product Hunt. Even a basic Ruby on Rails app would take me weeks to build. Although confident in my idea, I didn’t really know if anyone else would use a service like this. I wasn’t about to spend dozens of my nights and weekends building something no one cared about. How could I bring it to market sooner to test my hypothesis?
The 20-Minute MVP
It was unusually chilly that morning in San Francisco when I walked to my office, Philz Coffee. I ordered and claimed my usual seat. After unloading my MacBook, I peeked at my to-do list to find something I jotted the previous week:
In a burst of motivation to make Product Hunt a reality, I brainstormed ways to build a quick MVP to see if people cared to share and discover products. After noodling over a few ideas, I was reminded of Linkydink, a link-sharing tool by the friendly folks at Makeshift. Simply create a group and invite people to share links with other contributors and subscribers. Each day, the collection of posts are emailed to the group. “This is perfect!” I thought, mentally fist-pumping with excitement.
I logged into Linkydink, created a group, and invited a few of my startup friends to contribute. I wrote a quick blog post, announced the project on Quibb and tweeted.
Within 20 minutes, I had an MVP.
I sat back, sipping my coffee, anxious to see how people would respond.
Immediately, I received overwhelmingly positive feedback, first from Ash Bhoopathy, entrepreneur-in-action at Sequoia Capital.
Fun experiment, I’ve been wondering why something like this hasn’t existed on a larger scale. It’s probably the PM / growth dude’s best replacement for ‘Dribbble’ for collecting inspiration.
Then from a partner at Union Square Ventures, Andrew Weissman:
Love how you have all kinds of VCs subscribed! Build an angel list syndicate off this list and disrupt them (us) ;-).
And then from Talton Figgins, product support lead, Disqus:
Wrote this idea off at first when I first read about it but after checking out some of the recommendations (Peak, Sqwiggle, Calm, and Cycloramic) I’m hooked. Can’t wait to check out more.
Within two weeks, over 170 people had subscribed to product discoveries from 30 hand-picked contributors, consisting of startup founders, VCs, and prominent bloggers. Even more encouraging were the numerous unsolicited emails and in-person conversations expressing their love and support of the project.
It’s still very early but these signs of traction are encouraging, especially considering the minimalism of the “Linkydink MVP” and my (intentional) lack of marketing of the product. Granted, I didn’t launch the MVP with a blank slate. Years of blogging, relationship building, and projects like Startup Edition have given me an audience and network of supporters. The term “startup” is deceiving. Successful companies don’t start up overnight; they are founded upon years of experience and help from others that must be earned.
Now, For Building a “Real” Product Hunt
The results of the MVP gave me confidence in the idea: I had found something compelling. I began to research technology to build a complete product. Some of my engineering friends recommended Sinatra or Ruby on Rails. Unfortunately, I didn’t have any experience with these frameworks and while assured in my idea, I was still operating with many hypotheses of what the product could be. I wanted something sooner to test my next series of assumptions. I started to look into Sacha Greif’s Telescope, an open-source app for creating your own Hacker News or Reddit-like community. Pleased, I reached out to my good friend and designer/developer Nathan Bashaw to get his thoughts:
Yes! Eight days later, we launched Product Hunt.
An MVP is Not a Product
The “20-minute Linkydink MVP” was a great starting point. It allowed me to validate some assumptions very quickly and observe real user behavior without a single line of code. Entrepreneurs often assume an MVP needs to be “built.” The purpose of an MVP is to learn, to validate and invalidate assumptions. There are almost always faster ways to do this than building a product.
Next time you have an idea for a new product or startup, ask these questions before touching a line of code:
Identify your assumptions: What assumptions do you have about your idea? What must be true for the product to succeed? How do you identify your audience?
Test your assumptions: With your riskiest assumption in hand, brainstorm ways to validate or invalidate that assumption quickly. Use landing page tests, Wizard of Oz experiments, customer interviews, and other tactics to gather feedback from your target audience.
Learn and iterate: If your assumption in the previous step is invalid, reevaluate the idea and your target audience. If you’re lucky enough to be right, congratulate yourself and test the next riskiest assumption.
This lean approach and mentality was used to birth Product Hunt and its ongoing development.
Join the Hunt
Over Thanksgiving break, my talented friend Nathan Bashaw built the first version of Product Hunt. On November 26th we began seeding the community with a few select founding contributors. A week later, we formally launched in the press, receiving another healthy spike of adoption and feedback.
Visit Product Hunt and join the hunt!
This is just the first post of a series where I will share the strategies, tactics, and surprises we encounter building Product Hunt. Subscribe to my blog to follow along.
This article was originally published on FastCo.
Photo credit: eflon
Last week me and my buddy Nathan Bashaw, quietly launched Product Hunt, a community for product people to share, discover, and geek out about new and interesting products. Early feedback and engagement has been extremely positive.
Earlier this week we made it public. As PandoDaily reporter Carmel DeAmicis describes, our focus is on engagement and building a strong community that product people want to be a part of. Easier said than done. :)
I will be writing about the evolution, strategy, and surprises we encounter building Product Hunt. Subscribe to my email list to follow along and join the hunt!
The other day I received this notification from Instagram:
My immediate reaction is, “Andrew just joined Instagram!? JUST. JOINED. INSTAGRAM??? This must be a bug, right?”
After a few deep breaths, I collect myself and the disbelief fades. Reality sets in. And then I thank Instagram.
Thanks for reminding me I’m not normal. Living in Silicon Valley and working in this tech bubble is consuming. We live and breath technology, living on the cusp of innovation, playing with new products daily. But 99% of America, let alone the world, doesn’t live or think like us. Sometimes it’s easy to lose touch of “normal” life, blinded by the problems and realities of the 99%.
So remember, silicon valley friends: We’re not normal.
(Also, thanks Kevin Li for the reminder.)
As I approach my final days at PlayHaven, I’ve spent a bit of time reflecting on the mistakes I’ve made and lessons learned since joining the startup three years ago. I’m incredibly fortunate to have been a part of the journey. There were layoffs, heated debates over company vision, and other dramatic events worthy of a separate blog post (or two). But in the end, we found success, growing from a team of 10 to 100 since I joined.
Inspired by Sam Altman’s Startup Advice essay, here’s advice I wish I had three years ago.
IMPORTANT: I jotted these down between commutes from my apartment to the office. As with anything I write, take my advice with healthy skepticism. It’s all about context and admittedly these quick notes lack much of that. This record of learnings is written for myself more than anyone else. If you have specific questions or would like to swap stories, don’t hesitate to send me an email (email@example.com) or ping me on Twitter (@rrhoover).
- Don’t be so clever. Obvious is usually the better product decision. (tweet this)
- Have a vision and thesis of the future but don’t overshoot the market, ignoring what people ask for today. (tweet this)
- Error on over-communication (easier said than done). (tweet this)
- There will always be low hanging fruit but the ripest is often further away, harder to reach and see. (tweet this)
- Product complexity isn’t just a technical burden but an education hurdle for customers and new hires. Just because it’s easy to implement doesn’t mean it isn’t costly. (tweet this)
- Recognize we have a bias for hiring people like ourselves. Diversity is good. (tweet this)
- Hire people that intimidate you. (tweet this)
- Make ownership and responsibilities clear. (tweet this)
- Build a culture of accountability. (tweet this)
- Not every decisions can or needs to be defended with data. (tweet this)
- Intuition is underrated. (tweet this)
- It’s natural to feel under-qualified, in over your head in startups. That may be true but also recognize the Impostor Syndrome. It’s generally better to be overconfident than under confident. (tweet this)
- Momentum is key. Stagnation of innovation and constant negativity is draining and demoralizing. (tweet this)
- State the obvious, especially if it’s uncomfortable. (tweet this)
- Sometimes it’s ok (and unavoidable) to accumulate tech debt but make it a strategic decision, not a surprise. (tweet this)
- Fire quickly. There’s a reason this advice has become cliche. (tweet this)
- Who you hire ultimately defines your culture. (tweet this)
- The people that got you to phase A may not be the right people for phase B. (tweet this)
- Heroes - team members that do most if the work and hold most of the knowledge in a particular domain - are amazing and a huge liability. Heroes don’t scale. (tweet this)
- Have fun but maintain a sense of urgency and thirst. (tweet this)
- Celebrate awesomeness all the time. Especially the small things. (tweet this)
- It’s far better to be vocal and controversial than quiet and safe. (tweet this)
- The last 5% often makes all the difference. Follow through. (tweet this)
- Timing can be your best friend or worst enemy. (tweet this)
- Engage and include engineering very early in the product design process. (tweet this)
- In the words of Kanye, “Everything I’m not, made me everything I am.” If you’re saying “no” infrequently, you’re probably making bad product decisions. (tweet this)
- Product design and usability is important for any product. B2B companies don’t get a pass. They serve people too. (tweet this)
- Stay positive. Negativity is a cancer that will spread. (tweet this)
- Stop hating on competitors. Learn from them. (tweet this)
- Do “shitty” work. We naturally tend to prioritize the things we like to do over the things we should do. (tweet this)
This essay is a part of this week’s Startup Edition topic, “What lessons have you learned building your startup?” Read responses from other entrepreneurs at Startup Edition.
Subscribe to my blog for more essays on startups, product design, and personal growth.
Photo credit: quinn.anya
Nir Eyal shared with me this thought-provoking slideshow on compulsion loops and the increasing (and scary) influence technology has on our everyday behaviors. The entire deck is worth reviewing but slide 75 stood out to me:
Our culture, obsessed with numbers, has given us the idea that what we can measure is more important than what we can’t measure. Think about that for a minute. It means that we make quantity more important than quality. If quantity forms the goals of our feedback loops, if quantity is the center of our attention and language and institutions, if we motivate ourselves, rate ourselves, and reward ourselves on our ability to produce quantity, then quantity will be the result.
Donella H. Meadows (Thinking in Systems)
Frightening, isn’t it?
I blog a bit and as a result, people share my writing on Twitter. I use Tweetdeck to surface these mentions, creating custom columns to search for tweets that contain “ryanhoover.me” or URL’s to guest posts I’ve written on PandoDaily, for example.
In return, I reply to each and every person, occasionally reviewing my feed to reply with gratitude:
A few weeks ago, I started experimenting with something new. After replying with appreciation, people often respond in kind. At that moment, I send a second reply with an ask:
If this looks foreign to you, you probably aren’t familiar with Twitter’s Lead Generation Cards. By simply including a link within my tweet, the card is embedded, giving users the ability to subscribe to my email list with a single click. It’s beautifully simple.
As a result, 60-80% of people convert. Why?
They’re primed. They have already shown an interest in my writing and the small sign of personal, human interaction (e.g. “@grantwebster thanks for sharing, Grant! :)”) compels people to reciprocate.
It’s damn easy. With a single click, they’re subscribed. They don’t even need to verify their email address. By reducing friction, conversion increase.
I know what you’re thinking. That takes a ton of time, doesn’t it? It can. Although entirely manual, this small personal touch is part of its charm and why it works; however, there’s certainly an opportunity to automate and perhaps productize this process. A more automated approach would also reduce chance of a potentially awkward, impersonal interaction - asking already subscribed to subscribe.
I have some other Twitter card experiments up my sleeve that I’ll reveal in the coming days. Subscribe to my email list so you don’t miss out.
Have some Twitter card hacks of your own to share? Let me know on Twitter (@rrhoover).
"So what are you going to do?" My friend asked.
"Not sure. I’m exploring opportunities and investing in myself." I replied.
"Have you thought about joining a dev bootcamp to learn to code?"
Since I announced I was leaving my product role at a successful startup, several friends and followers asked me this question.
I considered joining a dev bootcamp. Yes, I would like to be more technical. Yes, it would be great if I could create my own RoR app. Yes, I might gain more respect from engineers if I could better speak their language.
But as with any decision in life and in startups, there’s an opportunity cost. Learning to code would be valuable but is it the most valuable use of my time? I don’t think so. And this is probably true for many others that join the coding bandwagon. They too would be better off investing elsewhere.
There’s never been a better time to learn to code. It’s more accessible than ever thanks to the open source movement, free resources, development frameworks, engineering bootcamps, and the helpful, generous coding community. It’s more lucrative than ever - it seems every tech company is hiring engineers, many of which gladly offer six-figure salaries for entry-level coders. It’s more glorified than ever as legendary investors like Paul Graham and films like The Social Network celebrate geeks.
As a result, everyone is learning to code. But should they?
Of course, companies rely on more than just 1’s and 0’s. Technology by itself isn’t enough - much more is involved in crafting a successful product and business. Software may be eating the world but that doesn’t mean technical talent is the sole driving force.
Flour Without Yeast Makes a Shitty Baguette
The two primary ingredients of a baguette are flour and yeast. Combining the two converts the fermentable sugars, present in the dough, into carbon dioxide and ethanol, turning the sticky, flat substance into a plump, airy treat. Without yeast, the dough will not rise.
Startups are no different. Most teams have flour - they’re technically savvy and know how to GSD. But what’s often missing is the yeast, the “non-technical” ingredient to grow their business. Products are built with technology, but companies need traction - the metaphorical yeast - to rise.
Great Products Fail
Metaphors aside, let’s take a look at the recent, unfortunate downfall of Everpix. As described in a postmortem, the photo-storing service was beautiful, awarded with over 500 reviews averaging 4.5 stars in the U.S. App Store. Its users loved the free service so much that an impressive 12.4% of them paid for premium upgrades. But it failed.
While the team obsessed about perfecting the service, the founders paid less attention to the subject investors care about most: growth.
Everpix built a good product, acquiring 55,000 users over the course of two years, but its modest traction didn’t reach the scale needed for continued VC backing. After burning through its cash reserves, the team was unable to raise another round to keep the lights on. Although armed with the technical talent to build a solid product, the team lacked growth focus.
Andrew Chen further described Everpix’s situation, commenting on the importance of traction talent:
The problem with hyper product-oriented entrepreneurs is that they often have one tool in their pocket: Making a great product. That’s both admirable, and dangerous. Once the initial product is working, the team has to quickly transition into marketing and user growth, which requires a different set of skills. It has to be more about metrics rather than product design: running experiments, optimizing signup flows, arbitraging LTVs and CACs, etc.[…] [A]n entrepreneur that’s too product oriented will just continue polishing features or possibly introducing “big new ideas” that ultimately screw the product up. Or keep doing the same thing unaware of the milestone cliff in front of them. Scary.
"I just want to code"
It’s not that technical people don’t recognize the importance of traction - most do. But coders want to code. That’s why they got into startups.
I recently spoke with a technical solo-founder. He described his challenges growing his social product:
I built the product in just a few weeks. It wasn’t hard. But getting users is tough! It’s been four months and I haven’t figured it out yet. I don’t enjoy marketing. I just want to code.
I hear this often. Coders tend to gravitate toward their craft because it’s what they enjoy doing. That’s what fuels late night commits and bug squashing. The passion to code often pulls them away from doing the important “shitty” work - the essential things they don’t want to do. Paul Graham describes this common mistake:
Most programmers wish they could start a startup by just writing some brilliant code, pushing it to a server, and having users pay them lots of money. They’d prefer not to deal with tedious problems or get involved in messy ways with the real world.
We want to work on our craft - the things we love and are good at - at the cost of ignoring more important things. We fool ourselves into thinking we’re making progress with each code commit. In reality we’re spinning. It’s fake progress. Of course this isn’t a characteristic of just technical folks. We all succumb to this, myself included.
Technology Startups vs. Tech-Enabled Startups
"Technology startup" is often a misnomer. Many startups might be better described as "technology-enabled." Several of today’s most prominent startups - Airbnb, Groupon, Birchbox, and Fab - reach their consumers through the web or mobile apps, but innovate in business and logistics more-so than technology. For these startups and many others, traction risk - ability to acquire and retain users - far outweighs technical risks, especially early on. Traction talent that can meaningfully contribute to the former, are in high demand as much as a coveted engineer.
Traction is Talent Underserved
Technology risk has been heavily de-risked because of the technical community. They got their shit together.
But you can’t build a successful tech company without technology and traction. Most of today’s startups don’t fail because they can’t build the product. They fail because they can’t get traction for their product. Founders continue to trust in the build it and they will come fallacy, launching with little thought in go-to-market strategy. They ignore the importance of sales, data-driven iterative design, and distribution.
These are “non-technical” responsibilities.
If it’s the technical community’s responsibility to build the product and the “non-technical” community’s responsibility to get traction, why aren’t more people in the latter investing in their craft to solve startups’ biggest weakness?
Don’t Take My Advice
I’m in no position to judge other peoples’ decisions. I don’t know your background, context, or motivations. Joining a dev bootcamp to improve your technical skills may be the BEST thing for you… or it might not. Before jumping on the coding bandwagon, ask yourself:
- What do I want to do?
- What am I good at?
- What does my company need?
If coding fits all three checkboxes, DO IT! If not, reconsider where you invest your time.
"So what are you going to do?"
Back to my friend’s question. As you might have guessed, I’m not joining a dev bootcamp.
I’m incredibly excited to be working with the team at Tradecraft, an SF-based incubator for traction talent, teaching kickass people the art of UX, Growth, and Sales/BD with top Silicon Valley practitioners and startups. Tradecraft is a fantastic opportunity to work with bright people to hone my traction skills and become a better marketer, leader, and product person. And teaching is one of the best ways to learn.
As announced Friday on TechCrunch, we’re accepting students primarily by referral. If you know of hungry, talented individuals looking to accelerate their learning and career, email me at firstname.lastname@example.org.
: Although not everyone working in tech needs to know how to code, it is incredibly important for non-engineers to have at least a broad understanding of technology.
: Several others have weighed in on the importance of learning to code. Here are a few:
Subscribe to my blog to follow my writing on product design and growth or say hello on Twitter (@rrhoover).
Thank to Russ Klusas and Misha Chellam for inspiring this piece.
Photo credit: Butaris
Yesterday I posted this tweet:
Minutes later, I received this email from Instacart’s CEO, Apoorva Mehta:
Apoorva could have simply replied to me on Twitter but he didn’t. He took the effort to go to his email, find my address, and personally send his thanks. Small signs of appreciation and effort like this build great brands and happy customers.
I’m surprised more startups don’t do this.
Last week I had the pleasure of interviewing Nir Eyal at the second Tradecraft fireside chat. As expected, Nir wooed the 120 attendees with knowledge bombs about habit-formation and user psychology. But I didn’t expect to be cartoonified in sketch notes!
Thanks, Kate Rutter!
I love Context, a “simple, fun photo texting” app by Ben Cera. The aptly named iOS app borrows elements from Snapchat and traditional text messaging to create an expressive experience that brings context to conversation. Each message is accompanied with a photo to color the interaction, as users share their point-of-view by taking a picture with the back-facing camera or snap a selfie using the front-facing camera.
I recently received this push notification:
"Cool! I wonder what Ben said." I thought while instinctively swiping the notification to open the app. Inside, I found this delightful surprise:
Ben used the app’s own messaging to announce enhancements and new features. Even better, he turned it into an opportunity to gather direct feedback, prompting users to respond with their ideas of how to improve the app. And people responded! Ben informed me that 25-30% of weekly active users reply to the message, a fantastic response rate compared to traditional channels of communication like email which typical returns a measly 2-4% click-through-rate. This qualitative feedback is incredibly valuable in understanding what users (think) they want and can inspire new ideas but it also fosters a stronger relationship with users through personal, intimate messaging.
We’ve become desensitized to sterile marketing messages but when there’s a bit of personality and human touch to the message, it becomes more memorable and often results in higher response rates.
Of course, Ben isn’t the only one using native messaging to communicate with users.
Snapchat famously announced Stories, its biggest update to the popular photo-messaging app. Each of its millions of users received a message, highlighting the new feature in a fun way with musical support from Goldroom.
But the company doesn’t limit native messaging to big feature announcements. Occasionally “Team Snapchat” sends an amusing selfie or snapshot of office shenanigans to its fans, adding personality to the brand and inspiring creation.
Polar, a mobile polling app, uses native messaging to educate users and prompt them to take a specific action. As users scroll through user-created polls, the app presents friendly, polar bear branded messages within the feed, asking questions like, “Want to see if your friends are on Polar?” If the user chooses “Yes,” a prompt appears instructing them to connect with friends.
These native messages command attention with less obtrusion than traditional popups, asking users to review the app in the App Store, share it with friends, and other actions to help the app grow.
Another one of my favorite mobile apps is Umano, a catalog of interesting articles and blog post read by professional voice talent. Its feed of articles from the New York Times, Medium, Thought Catalog, personal blogs, and several other publications play one after another. On occasion, the Umano team includes audio messages to announce new updates, inform users of free premium subscription, or simply say "thank you."
Unlike disruptive promotional announcements or ads found in Pandora, Spotify, and other music services, Umano’s native messages are no different than the content within the feed. Users can view them in the feed and skip if desired. Although self-promotional, these messages receive more attention and love in the form of “likes” and comments, than most of its other posts.
This should be obvious but a surprisingly large number of product creators fail to communicate with their users.
I see this often in gaming. Mobile developers continually invest resources and money into new levels, weapons, and other in-game content but fail to inform players they exist. One cannot assume users will discover it on their own - the app release notes don’t cut it, especially when apps auto-update via Google Play and the App Store. Much of the value - if not all of it - is lost if content additions are not made obvious to the user.
The beauty in native messaging is that it’s aligned with the user and relatively non-disruptive which is especially important where attention and real-estate in mobile is limited. Experiences that feel native are generally more delightful and result in higher response rates. According to a recent report, Facebook’s in-feed, native ads generate 28% higher click-through-rates (CTR) than its traditional desktop, right-hand-side banner ads. Another study used eye tracking technology and surveys to measure user behavior and sentiment to in-feed, native advertising vs. traditional banner ads. Unsurprisingly, participants viewed native ads 53% more but they also liked the ads more. Native ads resulted in a 9% lift for brand affinity and 68% more respondents said the native ads “is an ad I would share with a friend or family member.”
Although the industry is largely focused on the adoption and success of native advertising, the learnings and results of this growing trend apply not only to ads but any message that demands the attention or action of the user.
Consider how you can use native messaging to:
- Excite users with new feature or content announcements.
- Prompt people to share, review, or promote the app in creative, non-obtrusive ways.
- Educate users how to use new functionality.
What other examples of native messaging have you seen? Let me know on Twitter (@rrhoover).
Interested in startups and product design? Subscribe to my blog to receive a free copy of the upcoming book, Hooked, written by habit design researcher, Nir Eyal in collaboration with myself.
Nick Chirls of betaworks wrote a thought-provoking, relevant piece on Native Money a while ago. Worth the read.