Building in Public 4: How To Track What You Know (& Don’t) About Your Users

One thing I realise more every week is the importance of communication. It seems such a simple thing but can quickly grow complex and difficult as:

• Context changes
• People have different responsibilities
• People have different communication styles
• People have different pre-exisiting context

We always feel like there is more we can know about our users. Until recently we did not have one doc which acted as our source of truth for users. This meant a lot of context about our users was in my head but not communicated to the rest of the team. This month I looked to better communicate what we know (& don’t) about our users to the Steppen team. I will use this piece to highlight how we have gone about this.

Essentially we use a Kanban dividing:

• What we (think we) know
• What we a currently learning
• What we need to learn in the future

Nice and simple. Nice and effective. Let’s dive into what this actually looks like.

Step 1: Identify what you (think you) know about your users.

First list every question you have answered so far about your users e.g

• What is gender breakdown for our user?
• Where can we locate our users?
• How old are our users?

When I did this I started with the easy things like demographic information and then moved to more platform specific stuff.

This list needs to be updated consistently. It is important to recognise that just because you think you know something does not mean it is correct. That is also why I very clearly label this group of questions ‘Things we think we know.’

We always need to be gathering information and updating our user knowledge. This is not a set and forget task but rather a process. I have put in my calendar every Thursday so review the list of things we think we know. Sometimes I don’t need to (as not much has change) while other times I need to spend a couple hours updating things. Either way it stays up to date!

I format every question in the same way:

• Answer summary (let’s be real if there is a lot of information people won’t read the whole thing)
• Consequence: it’s nice to know something but what are the actions we are going to take to address this
• I also try to include EVERY piece of information we have which is relevant to the question (include links to relevant features, data etc,) in the cards so everything can be found together.

Example question answered

When I did this task I realised we know quite a lot about our users — we just had not put it all in one document. I instantly felt better about our user understand and was able to identify gaps in our knowledge, which nicely leads to …

Part 2: Identify what you are currently figuring out about your users

What questions are you currently trying to answer? Implicitly the features you are building are based on your learnings (or assuming things about your users).

E.g. we just built out progress pictures on Steppen, why? We realised that for our users like to visually see progress. This is the first feature we have built around progress. As we find out more about the importance of highlighting progress and how users like to see progress towards their goal we will tweak progress photos accordingly.

At Steppen we see 3 main ways to gather information and answer questions about our users.

1. Talk to users

• Good for theme based and qualitative questions, e.g. how do users stay motivated?
• Great for understanding why users are doing certain things
• Hack: surveys — not as good at getting detail but good at getting answers to multi choice style questions and broad themes which can then be deep dived into with user interviews. We also recently started UX testing, I am hoping this will become a weekly ritual for the team.

2. Analyse user product interaction.

• Great for understanding what users are doing e.g. how many people are searching
• Hack: using collected user information to answer questions. E.g in our case — what workout content do users like (can be determined by search terms and completions), what fitness level are our users at (can be asked in app and collected)

3. Market & general research

• Good to set foundation understanding of big questions e.g what are different ways people are motivated? What competitors do our users potentially use?

Often questions require a bit of all three. We are still working out the best way to integrate all sources of information.

Part 3: List things you still need to learn

Often when you answer a question it leads to another question e.g

• Qurstion 1: What fitness level are our users?
• Answer 1: Our users are beginners
• Question 2 (follow up due to answer of question 1): What is the best way to motivate a beginner to workout more?

Make sure you have a list of question you are yet to have even started working on. This makes helps ensure nothing falls through the crack.

Part 4: Communicate these finding with your team

• Put the document somewhere visible. We have this page sitting at the top of our team shared pages. Once we are all in an office together we will put this document up on a wall so it can be seen by the entire team.
• Communicate summaries, I try to send a more summary every 2 weeks to the team with any key changes.
• Discuss with team. We also discuss at our All Hands every 2 weeks key user findings with the team.

Some people will read /see the doc, some will look at the summary, everyone will be there for the team discussion. Between the three ways context should become shared.

Steppen’s Important Shared Pages (we love Notion)

Putting the Kanban together

That’s all from me for this month ! I have found this a game changer for understanding users. It organises your thoughts and helps build a coherent story about your users, would highly recommend. Any other ways companies track what they know about their users would love to hear. This is an area we can ALWAYS improve.

Until next month!

Cara 🚀