Getting comfortable being uncomfortable: sharing our early product screenshots & feature decisions

Hey, Indie Hackers! I'm the co-founder of Userlist.io: a behavior-based email automation tool to help SaaS founders communicate with their users at scale, based on actions users take (or don't take).

For about 6 months, my co-founders and I have been doing tons of customer research, collecting pre-orders of our product, and building our waitlist. Just last month, we finally started inviting our first few, super-early adopters into the product (hooray :)

Up until now, we've been really nervous to share actual screenshots of Userlist.io with anyone, or to talk specifically about our core features. Facing criticism and hard questions is scary! 😬

But, as one of our early adopters bluntly told us: "You need to get comfortable being uncomfortable."

So today, my co-founder & head of product Jane Portman (you may have seen her Indie Hackers interview last year) published a behind-the-scenes blog post, where she...

• Explains some of the feature prioritization challenges we've faced so far
• Shares actual product screenshots (!)
• Discusses how we're using feedback from early adopters to finalize our MVP

You're welcome to check out the original post here -- or keep reading below, where I've cross-posted the meat of the article.

We really hope this is interesting + helpful on your product journey, too!

--Claire
(Everything below was written by my co-founder, Jane Portman)

***

For context, here are the initial core features of Userlist.io that customers can expect:

1. Managing their list of users, and tracking each individual user journey.
2. Sending automated email messages based on user behavior.
3. Sending email broadcasts (like newsletters or announcements).

Now, I’ll walk you through the key screens and explain some of our product decisions. Our design choices were largely based on customer research, but also on my own experience with other email automation tools.

Disclaimer: these are merely design layouts which represent our current product vision. Since the core part of our strategy is promptly acting on user feedback, virtually anything is subject to change at any time.

User list

The heart of the product is the user list — hence the name. This simple admin panel allows SaaS founders (our customers) to see who exactly their users are, with names and key details like LTV or plan information.

One of the early frustrations with my previous SaaS product was the lack of such a user list. When I launched the beta version of that product, I realized that there was no UI to see my new users (unless I wanted to build a custom admin dashboard, which comes with a development cost). And my analytics tools only showed faceless data with session IDs! As a result, I opted for Intercom, but I can still remember that feeling — not being able to monitor such obvious information was frustrating.

• The columns can be customized to include properties specific for your business. For this sample customer, a fake company called Sparkle.io, it’s the number of projects that we want to see at a glance.
• It was important to make this table full width, so the filters are on top instead of being arranged in a side panel. Lack of horizontal space in tables can drive laptop owners crazy!

From the user list, the founder can navigate to each individual profile. Let’s see what these profiles look like.

User profile & activity feed

The goal for this screen is to provide an overview of the user data (including custom properties), and give us an insight about user activity.

The activity feed includes several types of events:

• General user activity like creating an account
• Custom events — what users are doing in the app (e.g. creating projects or adding content)
• Money-related events like converting from trial to paid, or being charged monthly
• Communication-related events — what messages were sent using our tool, and when they’re opened or clicked

Our goal is not to get as granular as tracking clicks or mouse movements: analytics tools like FullStory can do that much better. Instead, we want to paint a larger picture. We want to help you see what exactly led to a conversion, and how communication lines up with other user activities — without having to switch between multiple tools.

Automation campaigns

Behavior-triggered campaigns are the core of our automation. This screen shows how you can set up a campaign using four sections:

1. Trigger — a moment in time (typically an event) when the user enters the campaign. Once they do, it doesn’t matter whether they meet that criteria any more: they’ve already started advancing through the messages.
2. Messages — a list of messages that will be sent to the user once they enter the campaigns. The messages list features email stats (total sends, opens, and clicks) and allows for reordering and bulk actions.
3. Goal — an optional exit condition that allows you to terminate the campaign if the user meets the goal. As an example, you have a campaign that promotes a specific feature: there’s no point in sending further encouraging messages if the user already did what you need them to.
4. Next step — allows you to advance the user further in your pipeline. In this section, you could transfer the user to another campaign, or move them to another segment.

We had a lot of debates with Benedikt about how the automation system should look and work. We could have designed a visual workflow system, like ones you see in Drip or ConvertKit. But a few things stopped us from doing that early.

First, talking to other founders (and my own experience) shows that their existing automations are not very complex. Second, unlike marketing, where a customer can be passively taken through a hierarchy of content and infoproducts, SaaS users are way more diverse in their ways of using a product. Hardly ever there is an opportunity to determine a logical “tree” that truly requires visual automation. And third, we wanted to get enough user feedback before going down that rabbit hole. Building a visual engine would take 5x time and resources — which is 100% not viable at our early stage with so many unknowns.

Here are some other design decisions taken along the way:

• The left-side panel allows for quick browsing between campaigns.
• Each section (Trigger, Messages, Goal, Next Step) has an icon and a brief explanatory subhead that’s always visible. These explanations should help users understand (and remember) how automation works.
• There’s no global “Save” button — each section is edited and saved on its own. This should eliminate the confusion in updating things.
• Should the user want to edit a campaign that’s already live, we’ll automatically pause it (with a note) and then remind them to resume when they exit the screen. We’ll also send email reminders if the user forgets to resume the workflow. With other software, I remember myself discovering that my critical onboarding automations had been paused for a few months because of editing. I had no clue about it! Technically it was my fault, but the frustration was very real.

Message editing

A few design decisions should streamline the editing process:

• The left-side panel allows to quickly browse, reorder, and edit messages inside a campaign. If you used Intercom before, then you’d know that accessing the body of each message requires a large number of clicks which we wanted to avoid.
• Right now we’re planning on sending email messages only, but this screen allows to pick an appropriate channel for each message — like email or informational in-app message.
• We’re big fans of using Markdown for writing, so a simple Markdown editor will be available from day one. It may seem insignificant for those who aren’t raving fans (they can enjoy their traditional rich text editor), but it’s a specific point of delight for us.

Email look & feel

For the MVP, we had planned to have one email template — “plain text, but better” (see below). It’s neutral, but very polished: featuring nice typography, structured headlines, and an accurate footer.

However, our conversations with early paying customers made us change our mind. They liked our styling visually, but a lot of them would still prefer simple emails that look personal — as if they were sent from Gmail. So we will probably give founders a choice between the styled template and the “plain text” template. And down the road we’ll add custom styling, such as picking fonts and colors.

Settings

While none of these features will be implemented now, we have already thought about our settings. The screens below will give you an idea of the settings we’ll have eventually, like multi-user access and fancy billing. Launching publicly without a billing system is a very popular war story among many founders.

Which features do we build first?

Our product strategy is to collect as much early feedback as possible to inform further design decisions. But how do you collect feedback if the product isn’t ready, and you can’t give anyone access yet?

We made a conscious decision to “decompose” the app and give access to features gradually. For round one, which is happening right now, we’re working with the early adopters who pre-ordered the tool. Here’s the scenario we’re following:

1. We have a 1-hour onboarding video call with each founder (all three of us participating) to learn more about their business and their existing automation systems. These calls are recorded and transcribed, so that we get written insights for both product development and sales copy.
2. Benedikt works with the founders to get their user data flowing into Userlist.
3. Claire works with the founders (only those who need guidance) to identify their user’s “minimum path to awesome”, figure out what events to track, and plan automation content accordingly.
4. Founders get access to the very raw version of the app, which includes the user list and individual user profiles with activity feeds.
5. Founders get access to the automation section, being able to set up campaigns and write their messages.

In order to speed up the feedback loop, we decided to exclude email sending entirely from the first round. This decision dramatically helped us prioritize the features. If we’re not sending anything, then we can omit a big chunk of development work related to that. A good example of that is email and company settings: if you’re not sending anything, then there’s no need to have those yet. Also, email sending requires the largest effort to launch. It’s the most sensitive part where our system interacts with the ultimate users!

We’ve also omitted the broadcast features for now, because they’re rather straightforward and most founders shouldn’t have any problem using them.

Product insights gained from early onboarding

Having held a number of onboarding calls already, we have gained multiple new insights. Here’s the most important one: paying users find the main value in the “sending” part of the app. While user journeys can be tracked using numerous analytics tools (even though founders did like our implementation of the activity feed).

We also confirmed our hypothesis that founders set up fairly simple automations, but experience a lot of pain by having to go to their developer department for every single tweak or task.

All this knowledge will help us focus on the “sending” part of the product, safely leaving out traditional, more robust analytics features (for now or for good).

We look forward to your feedback!

Explaining the value of our tool — and what it does exactly — has been an important task for us, so we’d love to hear your feedback:

• Do the screens above meet your expectations for an early-stage email automation tool?
• If you already have email automations set up, what kind of emails are you sending to onboard and retain your SaaS users? What would you like to improve?
• Is the described version of the automation engine sufficient for your needs?

You’re also welcome to join our waiting list, if you haven’t yet. Thanks for reading!