For startups, one of the early challenges we encounter is to build empathy for users of our products across everyone in the company. If you are fortunate to have many users in exactly your ideal customer profile (ICP) and everybody interacts with users in one way or another, then the process may be simple: you just listen to them and build what they want. But what if you don't?
Our team was so busy focusing on building features that naturally most didn't have the chance to interact with users or use the product as our users would. This created a situation where our teammates were building for a user they know and somewhat understand, yet didn't have true empathy for.
To set expectations: this post isn’t about how to find a good problem to work on [1]. It’s about how to incorporate empathy for your ICP early in your product development process.
Before going through the approach we took, I need to share some context about why this approach worked for us.
Companies often struggle to create custom software to automate tasks for their customer, operations, and engineering teams, especially post product-market-fit. Dropbase helps developers build custom web apps and tools to support customer operations quickly and effectively, reducing the process from weeks to hours.
It was relatively easy for us to identify this problem, because we are our own users of the product. When we decided to work on Dropbase, we decided to build a product we wanted for ourselves.
So who are "we"? We are Python developers working in a B2B SaaS startup. We have customers that need support so we wanted custom tools to do it. Tools to refund customers, edit their workspace information, edit data in our backend database, change user permissions, activate customer workspaces, restart our internal AWS resources, update Lambda functions, etc.
There is a difference between knowing what product we want and how we’d want the experience of using it to be. One way to look at it is as the difference between knowing it vs. feeling it. Knowing what we want in the product informs functionality. Understanding how we’d use it or the feeling you get while using it informs the user experience (UX), which in turns further informs functionality. This creates a feedback loop.
Sometimes, even when you build a product for yourself and you know what it should do, you still don't really know whether you'd like using it the way it's built. That's because you might have a specific vision or mental model for how it should work that diverges from how it's built to work. Spending time to understand how it feels using your product allows you to get in the right mindset to truly understand your users's experience.
To further get into our users’ mindsets, we need to actually be our users. But this isn’t practically possible in the full sense because we can’t replicate the real-life KPIs, pain, pressure, concerns, deadlines, budgets, and other limitations that our users work with. So we need good enough approximations. For that, you could for instance invite engineers into onboarding calls, have them join sales call, or interact with users via customer support rotations. These are all proxies for building user empathy, but they are still not the real thing.
However, there is one thing specific to our case that we could do: we could pretend to be them. We could build apps and use apps using our own platform. We could place a deadline. We could add user stakeholders. We could go from beginning to end, learn and feel the entire experience, from signing up to building and using an app. It’s the closest approximation we can get.
Fortunately, we have the means to build empathy for the developer’s experience and the user’s experience. We are our own users. We build dev tools and are technical so we could just build apps using our platform and see how it works. And so we did.
Since we are essentially a web app builder and everyone in the team is technical, it only makes sense that we build apps using our own product to solve our own problems.
Below, I'm going to describe the process we followed that helped us build empathy for developers and users. The outcome of this process helps guide us to build the product in a way that it solves the problem delightfully (UX) and effectively (functionality).
Here’s what we did.
We needed to set the right mindset and framing for the team.
First, we made the explicit decision to invest in improving empathy for the user so we carved out time specifically for it. This meant reducing the tasks assigned to the team for the week i.e. shipping less in that particular week. Our team is always busy building and improving our product so this is an investment in the sense that there’s an actual opportunity cost. On a day-to-day basis, we tend to get lost in the details of specific product features, daily standups, or engineering discussions. We might occasionally zoom out to see where the product is headed int the next quarter or so. But there’s no explicit time set aside for actually doing something organization-wide that helps build empathy for users.
Second, we needed to be as hands-on as possible to get really close to the actual user experience. We wanted to replicate as much of the actual user experience as possible.
Third, we needed to get in the right mindset so we could reflect deeply about our users’ experience. We had to communicate how important this was. And specifically, how important it was for everybody to be involved in some way, either as a developer or as a user.
We had a list of use cases we wanted the product to be able to solve for. We just took the list of apps use cases we documented back when we first built the product and asked everybody to build it with Dropbase. We had a list of about 30+ use cases so to save time, we narrowed it down to the 12 that would incorporate all of the required nuances across the longer list.
Examples of use cases included a tool to easily look up customer accounts and refund them. Another was a tool to manage user workspaces so we could enable/disable workspaces. On the engineering ops side, we wanted a tool to manage our internal AWS resources and so on. See next section for a full list of use cases.
We had to experience the product as a developer that builds an app and as a user of it. We distributed the use cases among all team members to make sure everyone had at least 2 apps to build and at least 1 app where they are the users (an app stakeholders/reviewers).
For each app, we also wrote a high level description and explained it to the team.
Here’s the table I shared with the team with developer and user assignments
Based on the high level description, the developer and user synced up to agree on the app requirements and on the experience the user would like for the specific app (how it should work)
Here’s a sample app requirement.
We blocked out time with no meetings further meetings so everyone could get to building. Each developer took a a full day to build all the apps they were assigned to build. We cut our cycle planning for the week short to allow more time for this.
Here’s a screenshot of the blocked time in my calendar
One by one, each developer demoed the app they built. Then each user provided their comments on the experience of using the app as it was built. Then everybody else also provided their comments, making it fully collaborative.
During this process, we took down notes about the things that worked well, didn’t work well, and needed improvement from both a developer (DX) and user (UX) standpoint. We discussed the features, behaviors, or designs that could have made the app more delightful to use and faster to build. Here's a sample notes taken during the live all-hands call
The things we enjoyed become part of our value proposition and eventually in our marketing materials. The things we didn’t enjoy became ideas of how to improve the DX/UX. And the things that could be improved became part of our immediate roadmap.
From the feedback we got after the exercise, we collectively realized how useful it was. I could feel a deeper sense of empathy and excitement from the team. Multiple teammates DM’d and posted new ideas for what we could improve, or approaches we could take.
It immediately became clear what were some of the critical things the product was missing in each of the apps that were built. For example, everybody realized they wanted to bind button clicks to data table refetches. Without building and trying to use the app from the perspective of a developer and a user, this feature was perceived to be minor so we neglected it. But it turns out to be one of the most important features that would 10x the experience. Best of all, it's relatively easy to implement.
There were some issues that one or two teammates found frustrating early in product development, but only became clear to the rest of the team afterwards. Overall, the exercise built instant alignment on what was great and frustrating about the current design.
We realized on a different level what made the product stand out and different from what’s out there. For example, we realized how simple yet effective our apps are. We realized our approach is quite special - more so that we thought at the start, but that there are still a few improvements away to be maximally delightful for a larger number of app cases that we want to address.
We better understood limitations of our platform - it become immediately obvious which use cases we could and couldn’t tackle in a way that felt right. For instance, we realized that the product works best when the apps built focus on a specific task to automate rather than letting users build all tasks within the same page. Building and using the app for a specific task such as searching for a customer and generating an invoice for them was a much better experience than an all encompassing and complex billing dashboard that had many buttons and tasks you could trigger from the same place.
We came up with a list of specific UI components we needed and how we wanted them to interact. For example, we wanted UI display rules that dynamically display UI components upon row selections that contained a specific value.
We even wrote down ideas for helper libraries that would enable developers to build even faster.
This exercise was a big success. We not only got clarity for the product experience and refined our roadmap, but also better understood the parts of the product that are special and the parts that need improvement. We have a much better idea of how to the gap we need to close to maximize delightfulness and product function for the current iteration of the product.
Finally, we’ve generated many more ideas on how to improve the DX and UX, and already implemented some!
We were able to do all of this primarily because we are all developers and we built the product for ourselves to begin with. You should try this: build for yourself and be intentional about building empathy with your users.
Footnotes
[1] Check out Jared Friedman’s video https://www.youtube.com/watch?v=Th8JoIan4dg on “good problems to work on”.
