A Few Things I’ve Learned About Building Digital Products

Posted 6 months ago by Todd Goldberg

Over the past few years I’ve learned a lot about building delightful products that hopefully people love. Some have taken off. Some have been acquired. And some sort of went nowhere. More often than not, these learnings came from mistakes as I worked on a handful of web and mobile products. My experience set only comes from working with small startup teams rather than large teams at more established companies though I think these learnings still apply to both.

Prioritize features higher up in the funnel

In Andrew Chen’s essay “The Next Feature Fallacy,” he cites that your next feature will not drive mass engagement because all too often the feature is something that either too few people would use or makes too little of an impact when they do engage with it.

I’ve learned to prioritize features that directly contribute to primary business goals and still delight users, though sometimes these two functions can actually be diametrically opposed. Usually, these features are primary actions that take place during or shortly after onboarding. Features that are more geared towards power users have their place, but they won’t be something that everyone uses.

Focus on simple and hide the complex

Keep things simple. This doesn’t just include the simplicity of a feature, but also the product in aggregate. Every feature has a learning curve to it. Features that skew more towards power users or extend beyond core functionality shouldn’t be key parts of the experience. They could be hidden in the settings or deprioritized in the UI so their functions aren’t critical to the experience.

“Power user features often have the biggest learning curves as well.”

Ship as fast as possible because feedback is oxygen

Until you ship something, you don’t know how people will respond to it. Iterating in a black box — i.e. pre-launch — can be a dangerous place as your feedback loop is small. Launch what you’re building as soon as it’s ready. In my opinion, done is better than perfect for startups.

I’ve also recently become a fan of eliminating all dependencies to ship. This means not having to wait to get things like your marketing just right before engineering can push to production. Marketing and the way you position product and features can be iterated on, too.

Jason Fried, CEO of Basecamp, talks about this when describing how Basecamp’s mobile teams are driven by the same product vision, but yet control their own implementation schedules. This means their iOS team can work and ship independently of their Android team.

Break down big features and work towards them incrementally

I’m a systems thinker which lends itself well to approaching product. I like to break big features down into smaller components and then prioritize those components to get us from ground zero to a completed feature. I’ve found it helpful as a way to release things faster and provide more value to our users sooner.

I’ve also found it helpful to have a deep understanding of the full roadmap so you can understand how today’s releases will play into tomorrow’s product. This could be anything from current engineering limitations or level of effort to get something out of the door.

Vision drives the roadmap, but so should your customers

Everyone loves to quote Steve Job’s idea that the customer doesn’t know what they want until you show them. While I think this is partially true as great founders have a clear vision for what their products and impact will look like years or decades from the present day, your customers’ feedback is invaluable. This means you need to talk to your customers and make it easy for them to provide feedback.

“You need to talk to your customers and make it easy for them to provide feedback”

Your roadmap should equally encompass both parts. This is even easier if you’re building something to solve your own problem as you’re the end user.

If you build it, they will probably not come

Even if your launch goes phenomenally well, you’ll eventually enter what Paul Graham calls the trough of sorrow. Put simply, growth is hard. It takes a long time to find the right mix of growth channels and build a brand that people pass on to friends and coworkers.

And remember, there’s no such thing as an overnight success.

Todd is a founder of Mailjoy, a DIY tool to send direct mail postcards. Previously, he co-founded Eventjoy, a fee-free DIY ticketing company, which was later acquired by Ticketmaster. You can reach him on twitter.

This article was originally published on Todd’s Medium Page.

I design and grow products | Current: Mailjoy + Cardpop /Framepop | Past: founded Eventjoy (Acq. by Ticketmaster) | YC Alum

Related Posts

How my Sketch file started: a separate artboard for every type of Yammer thread. There were lots. Reducing our design handoff from 30 mockups to just one I’ve recently begun working on a design revamp of Yammer’s Android app, beginning with conforming all Yammer conversations to a 4px vertical grid for better readability. Because a single misaligned pixel could throw off the… Read More →

As designers, we create user flows and give them to developers, product managers, clients, and sometimes even users for testing. At its best, a user flow is a concise, clean, and compelling way to showcase the scope and vision of your application before it is developed. Oftentimes user flows are the key piece of documentation that we provide developers to… Read More →

I have a lot of friends who work in Growth, but I never really knew exactly what they did. Whenever our conversations turned towards “growth stuff”, I would always just smile, nod, and occasionally contribute a, “that’s really cool!” It’s not like I was clueless. I mean, I had an idea of what “Growth” meant — growing users, making money,… Read More →