I was invited to give a talk to university students on Wednesday (Oct 13th 2021) on start-ups and being a student. There were four speakers. We were each assigned a topic within the start-up lifecycle, ideation; financing; execution; or marketing and networking. I was assigned execution.
My initial thought when I saw my topic assignment — “Well we are in the middle of executing, we have not nailed execution yet.” Then it was, “If I am giving a talk on execution is the assumption we have executed well? Or even know how to execute (both I would argue we are figuring out)….”
I will use this building in public piece to highlight
- How one should go about execution
- The reality
- Two problems and subsequent learnings from Steppen’s execution process so far
What is Execution?
I will consider execution to be the time after your product launches. Prior to launch you are living in a fantasy world where anything is possible. You plan and project but you have no idea as you have no real data. Once you launch everything shifts. It is not a time of planning but a time of reactivity and action.
How do you know you are executing well ? You are building a product people want. How do you know people want it? You have a north star metric which keeps going up, you hear from users they love it, you are creating delight for users.
The Framework of Execution
I discussed this in my previous building in my piece Building In Public 2: Startup = A Bunch of Simultaneous Experiments 👩🔬. The common approach to executing in a start up is:
- Gathering Information: Product Data & talk to users
- Hypothesis: Based on information come up with what you think people would do in a certain situation.
- Test: Build something simple to see if correct
- Learn: did people behave as expected ? Why did they behave this way?
- Refine and repeat: take those learnings and start gathering more information so you can roll through the cycle again coming closer to building something your users want.
In Reality
All frameworks seem nice on paper. Reality bites. It takes real discipline to follow the above execution framework. Real life requires a bit more gut feel here and there and adaptability than strictly following a framework.
Frequently, I need to remind myself of this framework and as a team we need to revisit experimentation. While from the outside start-ups seem to follow a clear trajectory from lightbulb moment, launch and then meteoric rise. Often the problems they face are hidden. This ‘outside view’ is unhelpful as it paints an unrealistic picture to both the public and first time founders about what being involved in a startup entails — grit and perseverance.
While Steppen is growing and improving daily, the road has not been without obstacles (and we will continue to face them). What is key to a startup’s success is not the abscence of problems but how the team reacts, learns and improves from them. Here are two major problems we have faced and how we have addressed them.
Information Problem
Problem: Step 1 of the execution model I have highlighted is gather information. In early September we had now been in the market for a couple months yet we still felt we did not have a deep enough understanding of who our users were. I, as the product person, particularly felt like I was letting the team down and it was my responsibility to know who our users were. We had to get more information and fast.
So we did a few things:
- We added year of birth and gender to our onboarding process
- We cleaned up our product analytics which was a mess (this is still a WIP)
- We sent out a survey to our users
- We got on the phone and started calling users
- Finally, we added one more step to the onboarding process asking users why are they here
As soon as we started collecting this information we asked ourself why were we not doing this earlier…
I am proud of our fast turn around. Suddenly, we had a lot of information coming in and very quickly understood who exactly our users are, their gender, age and why they had joined Steppen. We now have a clear image of typical Steppen user.
Key learnings:
- We need to esure we are constantly gathering information. Gathering information should not be a ‘sometimes thing’ but an always thing. It is naive (and dangerous) to think you truly know your users as that breeds complacency.
- Collect demographic information. It makes you straight away feel like you can understand your users better.
- Sometimes you have to put things in the calendar and put frameworks around them. It can be easy in a start-up to think, ‘Yeah I will get to it.’ But then you just don’t because something more important//urgent comes up. There are some things which just need to be done. I now have a bunch of weekly tasks (taking a leaf from my well organised co-founder Jake’s book) which ensure we are consistently looking at important information and adjusting our efforts accordingly. This has been a real game changer for my work flow.
- Every interaction with our users is an opportunity to better understand them so we can build a better product for them.
- Having data but not analysing it is the same as not having it (thus why one of my weekly tasks is to ensure we are on top of our data)
- You want a good mix of quantitative and qualitative information as both provide different insight. Relying on a single stream e.g. product data but not talking to users is not enough.
Focus Problem
Problem: As we did not have a enough clarity around the identity of our users, we lacked focus. We were trying to tackle too many things at once. There was no common thread between the things we were building. We needed everyone rallied around a shared problem.
What we did: Now with information, some reflection and great discussions we realised what we had to focus on. We found less is more. Previously we had been trying to achieve three things at once (fix UI/UX, improve content production and help users achieve their goals. Now we are focused on one thing = helping our users achieve their fitness goals. Once we realised our focus I had to ensure that was communicated to the entire team.
After we articulated our focus I felt super relieved. It was clear what I needed to care about and what did not matter. It felt great saying to the team, ‘No I don’t care about that as it’s not related to our current focus.” It was exciting to see how everything we are now working on is clearly intertwined. And it is rewarding to be the one to communicate our company prioritises to the team.
Key Learnings:
- Personally I learnt a lot. As CEO it is my role to communicate context and ensure alignment across the team.
- Just because something is clear in my mind it does not mean it is clear to others. It’s my responsibility to ensure the team understands what is important along with how their work ties into the bigger picture. There is a saying that goes something like when you are sick of saying it, that is when everyone is starting to hear it. It is important to live by that.
- It is freeing to be able to say I don’t care about that problem. It makes work and focus easier.
- Understanding the ‘why’ makes everyone understand their role and importance in the team. Without the ‘why’ people need more information and management. Not a good use anyone’s time.
In Conclusion.
We are still learning how to execute and improving. I am stoked to be embarking on this next stage of execution with the Steppen team. As a user of Steppen I am excited to see all the changes to come. As a member of the Stepppen team I am proud to be working with everyone on a problem we care about. And as a leader of the team I am eager to continue to communicate context to the team.
Until Next Month 🚀
— Cara
—
This was my third attempt to write my building in public piece #3 but this attempt felt the most fitting in summarising where we are at 🤩
