I co-founded Whywhywhy with Matt Holden in 2021. Whywhywhy was a team-based analytics app designed for broad appeal: Multiple use cases, multiple personas. We wanted to create an app with low floor and high ceiling so users could grow into more advanced use cases over time (like Excel or Tableau).

This writeup is a play-by-play of how we designed and built Whywhywhy. If you want to see what the finished product looked like, head over to whywhywhy.com. We also wrote a post mortem that goes deeper into the market and business.

Whywhywhy editor

Why does the world need another analytics app?

As product builders, we had used many analytics and business intelligence tools and were frustrated with their limits, mainly how they got in the way of our curiosity. Most business users we talked to felt a similar pain as they were trying to use data to answer questions. We heard a lot of frustration with current analytics tools, and most normal users still relied on spreadsheets as their data tool.

Frustrating questions

Curiosity turns into frustration when using data

Data infrastructure was also changing, with technologies like Snowflake, dbt, and the metrics layer promising a future beyond heavy BI tools. We also saw an opportunity in WebAssembly, Apache Arrow, and DuckDB—technologies that allowed the browser to handle large data processing tasks.

The no-code notebook

We set the audacious challenge: How would analytics work if we rethought the tool from the ground up? Looking at the existing landscape, we saw a few issues:

Tool Pros Cons
Spreadsheets Flexible
Doesn't work with large datasets
Charting is an afterthought
Terrible for storytelling
Dashboards/BI Good for monitoring
Bad for exploration
Bad for storytelling
Vertical analytics
(Mixpanel, Amplitude, etc)
Approachable Inflexible—can’t bring in outside data

Enter the notebook. We liked Jupyter and other computational notebooks for exploring data and communicating insights. The problem is that you have to know how to code, which makes it inaccessible to a broad audience.

Jupyter notebooks

What if we could design a data format that took the best parts of the computational notebook but made it accessible to folks who don’t code?

We started with a keyboard/natural-language-driven interface. The prototype above is one of the first we made to see if the concept had legs. As you can tell by the sample data, this was right during the COVID-19 pandemic.

We wanted a format that let you explore data and create a compelling narrative once you had found your insights. Above is a prototype of viewing a video narration embedded in an interactive document.

Users liked the speed (fast “time to table” and “time to chart”) and direct interaction paradigm (point-and-click instead of writing formulas) of the no-code notebook prototype we had made. The document format was less compelling, however. Users already have a go-to document tool and don’t necessarily want to add another one to the mix. One PM Director summarized the feedback well:

Most people don’t want to write or read long documents. What’s more interesting: How do you facilitate the conversation around the data?

The question card

Inspired by constrained communication formats like Instagram posts, we pivoted to a direction based on “question cards”. We designed question cards to be embeddable in other tools like Notion and Slack and tell a single data story.

Card gallery

Above are some example data stories from our own work experience. This more straightforward, story-focused format resonated miles better with users.

To constrain the design space, we started with mobile as a canvas. It helped us identify which elements were minimally needed to create a compelling data story.

We re-engineered the notebook editor to resemble presentation software. Each card has a flexible recipe of transformation steps inspired by dplyr and node-based creative tools like Origami, Houdini, Max, etc.

Origami Studio

Origami’s building blocks can be assembled to create complex behavior

dplyr pipeline

A dplyr pipeline using a small set of composable verbs

The idea was to provide the building blocks of data manipulation that users could use to assemble higher-level recipes that others could remix. We had left the concept of business users self-serving and felt that the challenge was to solve collaboration between business users and the more data-savvy folks in an organization.

After user testing the first card prototype, we dialed back the rigidity of the slide/presentation structure. We brought back the fast fluidity that we liked from the notebook while still keeping the “cards on a board” idea.

Whywhywhy editor

We designed question cards to follow a few principles:

dplyr pipeline

Interactive card embedded in Notion

Whywhywhy viewer showing collaboration features

Explore the data and remix it to answer your own questions

Whywhywhy viewer showing the source of the card including SQL query

Viewers can inspect the source of any card to see how the analysis was done

Whywhywhy browser extension in BigQuery console

Create cards straight from your SQL editor using the browser extension

The brand

We wanted something that felt quirky and had a human touch. Existing tools used a lot of imagery of networks, computation, and automation. Because we believed in the importance of a human adding their narrative and judgment to the data, we wanted a brand identity with more humanity to it that reflected how we were different from other tools in space.

The name came from our focus on questions, and we liked that it was unique and memorable. So many startups are named some generic five-letter word. To be remembered, you have to be a bit weird sometimes.

Whywhywhy home

While the app had an overall restrained visual identity, we sprinkled a playful hand-drawn look into places like thumbnail placeholders.

Whywhywhy iconset

Icon set — 20x20

Whywhywhy colors

Color swatches

Whywhywhy charts

Whywhywhy chart style

Lessons learned

Designing a new general-purpose data analytics format was audacious. While we didn’t reach all the way, I think the principles we discovered are essential for improving how people answer questions using data and are mostly missing from today’s analytics tools.

We talked to hundreds of data users in various roles, learning about jobs to be done, ideal initial customers, and wedge use cases. It was exciting because the user pain was quite evident.

But adopting a data tool has significant frictions (data access and security are the main ones), and we found it hard to find a tight first use case where the value of solving it is larger than the cost of adoption.

As the data stack continues to improve over the next few years and makes it easier for end users to access clean, usable datasets securely, I’m sure we’ll see better analytics tools too.