Reflecting on 2018: achievements, lessons, and struggles

12 months ago, Dovetail was a brand new product with a handful of features and users. Now we have hundreds of happy customers, thousands of active users, a deeper understanding of the problems we’re solving, a larger development team, and a much more functional (and valuable!) product.

We didn’t have any experience doing this before. We also didn’t have any, advisors, investors, or mentors. We simply tried to follow an iterative process of listening to our customers, learning, and improving the product.

With 2018 behind us and 2019 ahead, we thought it would be a good exercise to summarize the things we did consistently; both as a record for ourselves, and in case there’s something useful here for other founders.

Here’s what we whittled the list down to:

1. Learning from our users

2. Focusing on a specific problem

3. Prioritizing with principles

Learning from our users

Dovetail users are researchers, designers, and product managers. This is helpful for us: people in these roles know how to give great feedback and targeted product suggestions. They understand the challenges with product development since they have their own firsthand experience.

Brad and I aimed to establish close relationships with early users when we started working on Dovetail. Naturally we wanted to hear their feedback on what we were building, but since neither Brad nor myself are researchers, we were also keen on uncovering new problems for us to solve.

One of the more successful ways we’ve been staying in touch with our users is through our public Slack community. This was a bit of an experiment and we weren’t sure if anyone would bother to join, however, over time, the community has grown, and it has enabled us to have ongoing conversations with a small collection of smart people around the world. This rapid feedback loop has been hugely beneficial for our product development; people aren’t afraid to ping us directly with bug reports, and we often drop design mockups for upcoming features or questions we have to spark conversation.

We also communicate with users regularly in-person, over video chat, through our in-app feedback form, and on Twitter. We use Zapier to store all of this data in Dovetail, where we categorize it with tags. This helps us uncover patterns, quantify feature requests, and track pain points over time. It also means we have an easy-to-access repository of contextual user feedback and research data that we can refer back to whenever we start work on a new feature or begin to improve an existing one.

When we have a meeting or video call, we often show design mockups and concepts for new features. We let users know when we launch something in beta and look forward to their thoughts. When they encounter bugs that are easy to fix or have straightforward feature requests, we try to act as quickly as possible. Often we release a new feature just hours after someone asks for it.

We also visited our customers in Sydney or invited users into our office for co-design workshops. Our users helped us design new features and make decisions about their behavior.

Our transparent communication, strong relationships with users, and rapid execution meant that early users started to trust that we were competent enough to solve their problems and execute well on new features. Even if the product didn’t do what they wanted it to do at that moment, early users understood we would get to it one day and execute well.

Focusing on a specific problem

Our original mission statement was to help teams store, organize, and analyze both customer feedback data (like survey responses, tweets, support tickets, and in-app feedback), along with user research data (like interview transcripts, usability testing notes, photos, and videos).

We felt there was value in having customer feedback and user research data in the same place, and that the use cases were similar enough that a single product could tackle both. The reality is that the features required to analyze and organize customer feedback is very different to user research data.

For example:

• Feedback is high volume (thousands of items) whereas user research is typically low volume (dozens of items).

• Feedback is short-form (hundreds of characters) whereas user research is long-form (thousands of characters).

• Feedback is best analyzed automatically due to the volume, whereas user research can only be analyzed manually (with current technology).

• Feedback is constantly arriving, with no end in sight, whereas user research projects finish at some point.

• Feedback typically originates in other tools, and so is heavy on integrations, whereas user research is less reliant on integrations.

We realized we were building one product to do the work of two. On top of this, the customer feedback market is extremely competitive, and we knew we couldn’t compete in both at the same time. So we pulled out of customer feedback, removed a couple of features, and repositioned Dovetail to focus on user research for teams.

By realizing we were spreading ourselves too thin, we simplified a lot for ourselves. The product is now clearly positioned to solve a specific set of related problems rather than two distinct problems. Our marketing messaging has been simplified; it no longer needs to communicate many things at once. And, most importantly, it has made it easier for us to make prioritization decisions.

Prioritizing with principles

Prioritization is crucial for an early startup. Startups are resource-constrained yet highly ambitious. Making the right decisions about what to build next is a balancing act of tradeoffs, and we discovered it was important to have a few principles to help guide us in the right direction:

• Play to our strengths. Brad and I have certain strengths from previous experience which makes some things ‘cheap’ for our team. We try to prioritize things that play to these strengths. For example, we’d rather invest in making the product self-explanatory than rely on sales demos or comprehensive help docs. We prefer to create ‘fans’ who share Dovetail with their network instead of spending time and money on paid marketing where we have little knowledge. Figure out what’s ‘cheap’ based on your experience and what’s ‘expensive’, and prioritize the cheap stuff.

• Create a great experience. Design is a huge differentiator for cloud products, and given that we didn’t have a lot of features early on, we knew we needed to make up the package for customers by delivering a great experience. This translated to a well-designed marketing website, a self-service onboarding experience, straightforward day-to-day product usage, responsive and friendly customer support, etc. Focusing on design plays to our strengths, separates us from the competition, and make the product more valuable (usability is very valuable).

• Follow the law of diminishing returns. A feature that’s 80% done is usually good enough. The last 20% has a diminishing return. We often release features that are 80% complete in order to get quick feedback and move on to the next one. Combined with our modern codebase and prior experience, this enables us to release a lot of features in a short amount of time. An important thing to note is that we never compromise on design or polish. We compromise on functionality. In other words, a given feature won’t do everything we want it to, but what it does do, it does well.

Lastly, user expectations are very high for business-focused cloud products thanks to mature tools from companies like Google, Atlassian, Microsoft, Salesforce, and so on. When Dovetail was in its infancy, it didn’t have ‘basic’ features like search, import / export, integrations, and permissions. Right now it’s still missing core features that users naturally expect from their experience with other tools, like notifications, comments, and user management.

We had (and still have) a real challenge balancing these ‘table-stakes’ features with differentiating features that people actually buy Dovetail for. Users ask for table-stakes features since that’s what they expect from other tools, and indeed, some companies still make purchasing decisions based on a checklist of requirements. It felt very easy to simply end up with a piece of software jam-packed with features that actually did nothing valuable.

Following our principles above, and many more I haven’t covered here, we released a lot of features in 2018: bar chart, bulk editing, collaborative editing, CSV import / export, custom colors, domain-restricted signup, formatting toolbar, full-text search with querying, hyperlinks, images, and files, improved billing system, improved navigation, indented list items, inline audio / video previews, project access control, project categories, project templates, sentiment analysis, tables, trash, user onboarding, and a Zapier integration.

2018 was full-on and extremely tiring, but overall it was a great year for Dovetail. We’re thankful for all of our customers, friends, family, and everyone else who have helped us get this far. We couldn’t have done it without you.

In 2019, we’re focusing on becoming the obvious user research platform for businesses. This involves a lot of product development, hiring, and changes to become great at day-to-day operations.