wireframing the future article cover

This is the story of how Dovetail went from one single platform for researchers worth around $30 million to a multi-product company that serves a diverse range of users, worth north of $700 million. And how wireframing led us there.

In this article, I'll explain how I initially failed in delivering a product strategy. And at the risk of sounding trite—how that failure laid the foundations for eventual success, including an entirely new product direction for Dovetail.

Early days

I joined Dovetail as its first full-time designer. Early on, I sank my teeth into a large-scale generative user research study to define our product’s next tent peg feature. We were still a single product company, and our go-to-market strategy revolved around research. My goal was to figure out how we could expand our offerings and capture new markets.

The research project and findings became the centerpiece of ongoing strategy meetings involving a core group of high-context individuals, including our CEO, CTO, and a number of early-stage employees. We debated the insights, aligned on the problems, and eventually found a solution: a feature—or what I thought was a feature at the time—that would revolutionize the way our customers used Dovetail. Tentatively named Collections—this new feature would greatly expand our repository solution, solving multiple problems for not only researchers but their stakeholders as well.

Many designers out there probably know the feeling—for so long, we’ve been fighting for a seat at the table. Not only did I have one, but I was given free rein to define the company’s future. It was an exciting time.

Unfortunately, things took a different turn. We went in a very different direction from what we had planned.

Zen and the art of stakeholder buy-in

Landing on a great solution and getting buy-in from key stakeholders is not a one-and-done. This is probably the biggest lesson I learned. First, solutions change. That’s just the nature of product development. As new information becomes available, we need to respond and adapt. Second, that initial buy-in I got from the group of high-context individuals was lost as information and context changed.

It’s also important to think about the people outside those meeting rooms—the engineers, designers, and all stakeholders involved in executing the project—because you will need their help more than anything if you expect your product to have a future.

This is my biggest advice to anyone out there creating a product strategy: continually build buy-in with key stakeholders and everyone else involved in the process. Bring them along for the journey.

lucy denton headshot

Lucy Denton, Head of Design at Dovetail

With this, always consider how you are communicating your message. In my case, I presented research insights as highlight reels in Dovetail and then a solution. But, I was missing another element in the middle: a piece that validated the solution and explained why it was the best thing to build at that moment.

Where it all broke down

Ultimately, the lack of alignment culminated in a watered-down compromise of a feature that eventually failed. I learned that you can’t be successful unless the entire team understands why you’re doing something.

It was time to have a tough leadership meeting to reckon with the direction we had taken up to that point and figure out what went wrong. Why had we all been so excited about this new product direction just a few months prior, only to see it die on arrival?

One of our first breakthrough realizations was that our go-to-market messaging wasn’t aligned with the new product direction. This messaging isn’t only for customers—it impacts how internal stakeholders perceive the product they’re building.

We looked back at the research we had done and the problems we were excited about solving and realized that we were solving problems for different buyers and primary users, who all needed different things from the product. That’s when we realized—we’re not trying to build a new feature—we’re building a new product.

Wireframing the future

The relief flooded in all at once. To deliver our vision in a meaningful way, we needed to change our thinking and start conceptualizing what we once thought of as features—now as products. I won’t lie, we got a little ahead of ourselves. It almost seemed like every Dovetail feature could be a product! Eventually, we whittled it down to three:

  • Playback: our repository solution
  • Markup: our suite of analysis tools
  • Backstage: our solution for participant management and tracking

We thought we were onto something, but as designers, we needed to visualize what these new directions would look like to see if they worked.

Our CEO is a designer and worked closely with me on the project. We did what designers know best and began developing our product strategy in wireframes. We sketched and started feeling good about our direction. Through wireframing, we pulled in other people to get feedback on our work. The product people were mostly unphased by this unorthodox strategy presentation, but a few eyebrows were raised by people less familiar with the design process.

What is a design-led product strategy?

Before I jump into how we wireframed our strategy, I want to dig into what I mean by “design-led” strategy.

In many traditional companies, sales and marketing are the driving forces for customer acquisition, retention, and business growth. However, more recently, we’ve seen the emergence of “product-led” growth companies that focus on the product as the driver of business growth. The outcome is a more customer-centric approach to developing products and achieving business goals.

At Dovetail, product-led growth means looking at strategy from a design lens first and foremost. Design is intrinsically user-focused—the view is that profits will follow if the product experience is tailored to the customers’ needs.

That’s why we chose wireframes as a medium for communicating strategy instead of marketing or sales data. Wireframes better represent what the customer experiences. They’re grounded in the user journey. Hence, a design-led product strategy is one that has the customer and their needs firmly at its center.

Wireframing a strategy isn’t a common approach—and it wasn’t something that made immediate sense to us. In the next section, I’ll provide a few tips on the wireframing process for anyone who is considering this method.

Our design-led strategy process

If you’re thinking about wireframing your product strategy, here’s what we did and learned.

Start with your GTM messaging

Similar to popular “build-a-box” exercises where you imagine what the product packaging might look like, we began by creating landing pages for each product we wanted to build. These weren’t supposed to be the final landing pages. The exercise was about creating alignment, as it forced everyone to think deeply about the value of the products we were creating. In line with a customer-centric mindset, a landing page is also the first thing a potential customer will experience in their journey. If you can create a compelling LP—you might have a good product on your hands.

Build a component library

Next, we created a component library so we could execute multiple wireframes at speed. By providing a basic set of UI components, our stakeholders were able to mock up their own wireframes and clearly communicate their vision of the product. Protip: We made our components, but you can also download a library for free!

Create the wireframes

After we developed a component library, we mocked up multiple feature ideas to explore how they might solve different customer problems. Wireframes are usually a way to map out functionality, UI, user flows, and information architecture. However, in the case of wireframing a strategy, they are purely a way of articulating an idea. For this reason, remember the following:

  • Keep it low-fidelity. You don’t want people to get into the details, or to think the product is further along than it is. The more basic the wireframe, the more you draw the focus on the solution rather than other visual elements. Our wireframes were incredibly simple 800x600 screens.
  • Get everyone involved. As I mentioned above, we provided our stakeholders with a component library so they could show us what they were thinking rather than tell us. This helped us bridge the gap between what people were saying and what they actually meant.
  • Bring in core stakeholders early. We got started in a few hours, created components, and as soon as we had visualized two or three ideas, we showed them to our key stakeholders. This makes them part of the process of envisioning the direction and helps to get their buy-in from the very beginning.

Synthesize your results

After getting feedback and aligning our expectations, we ended up with many different wireframes representing different features and aspects of the three products we were trying to visualize. Now, it was time to deepen our understanding of how our features aligned with the new products.

We mapped the features across the user journey, starting at the landing page and sign-up flow all the way through the research journey with all its various jobs-to-be-done, documenting different scenarios along the way. Through this process, we validated our assumption that there were indeed different buyers and users of the Dovetail platform, and that his formerly unified product could be separated into the three products we envisioned.

Wireframes and beyond

When people say “product strategy,” long documents packed with reams of analysis, charts, graphs, and tables come to mind. Serious businesses don’t create strategies in Figma. But the truth is, I found them to be an effective way of communicating our solution. The issue we ran into previously was a lack of alignment between what we agreed on in strategy meetings and what that actually meant once the rubber hit the road. Wireframes allowed us to communicate visually to our stakeholders, get their feedback, and ensure we were speaking the same language.

Eventually, we shared an interactive prototype of the three products with the rest of the company as a way to tie the research insights we’d generated to a tangible solution. We continued to evolve the prototype by creating a wireframe library. Every time our designers create a new feature in wireframes, they add it to the prototype so that it lives on as a source of truth for our product strategy. Whenever a new person joins the company, they can jump in and see where we’re going.

Wireframes allowed us to be certain that we were aligned—they were the missing piece of the puzzle that connected the problem, the solution, and the why behind our multi-product vision. If you’re a designer looking for buy-in and alignment on your next big project—give it a try and let us know how you go.