27 May 2020
The Equalture Story (10): Starting as the first Product Owner
The Equalture Story. A series of stories to give you a look behind the scenes of our company. Milestones. Failures. Lessons we’ve learned. Just the honest story about a SaaS startup trying to conquer the world.
In this tenth story: How it was to start as the first Product Owner and the three most important things in my first few months.
Starting as the first Product Owner at Equalture
Approximately 3 months ago I started as the first Product Owner at Equalture. This was also the first time that I started as the first PO in any company. Though, I shortly worked for another start-up both situations cannot be compared as both companies are in completely different stages.
Being the first PO at a company brings in all sorts of extra challenges, because it’s such a centralised role between both the commercial and technical side of the business. Just consider the fact that most people had never worked with a PO before and now suddenly everyone has to work with this person. What can we expect from this guy? Like Fleur, one of our founders said: “What does a PO do in his first weeks? I can think about this for every role, but for a PO it’s hard”.
Well, when I started basically the entire development team was new, which meant that we have to get to know each other, the product, form our processes, etc.. Everyone had his or own way of doing things and we needed to find our way of collectively doing things. Oh and by the way, we had to do it all online. Most of us only saw each other two weeks at the office before we had to work remote.
So, besides the things that everyone else does when starting a new job, what did I do in my first few months? I’ll tell you by highlighting the three most important things.
Lesson 1. Doing things right vs. doing the right things
Doing the right things is probably the most difficult thing for any start-up.
Especially for a starting Product Owner it’s impossible to tell what we need to do immediately. I’m not walking in on my first day exactly knowing what needs to be done and in which order. Therefore, I focus on facilitating events where we determine this with the people who do know.
However, we have limited resources to always have the what perfectly clear anyway. We do not have months to research our own ideas and vision. We do not spend weeks on interviewing,designing, iterating and a/b testing.
So, we said, let’s lay the foundation of this ideal world scenario, while we as a team in the meantime make sure that we focus on doing things right. In other words, we know how to execute any what that we want.
Let’s hypothetically say that we always know what to build, then we are perfectly capable of executing on these wishes.
In the meantime we rigorously improve our ways of finding out what we need to make.
Lesson 2. Making sure that everyone speaks the same language
Getting to know everyone personally is not that hard. Getting to know everyone’s way of working and making sure that these align takes a bit more time. This is also called norming (Tuckman model). It’s the third phase, after forming and storming, and before performing.
When looking at the development team, we worked on creating new norms. How do we write stories? When is a story considered done? Do we need a definition of done? How do we release? When do we inform each other? How do we do things such as stand-up, sprints, retro’s etc.. Yes, it’s making sure we have the basics in order. Without these basics we will never be able to become a high performing team. We need to know everyone’s position on the field and we need to learn how they like to receive and shoot the ball in order to score. We need to be able to trust each other.
Communication to stakeholders, however, is a lot tougher, because they aren’t involved in every stage of the development cycle, and therefore require different communication structures.
Hence, we started ensuring that we speak the same language as well, meaning that we adhere to the same processes and that we understand why we do things in such a way. How do we get feedback from Customer Success and Sales to the PO and development team? When will something be added to the roadmap? And where on the roadmap? What is the team working on and why? What metrics do we want to improve? Which information do I need from a stakeholder and what is the best way to collect this information?
I believe regular communication is key. For example by creating a transparent roadmap, providing regular updates via mail and live in demos. Also, creating moments where stakeholders can give feedback are very helpful and even necessary. In the end, we cannot speak the exact same language immediately. We are constantly learning and improving with lightning speed.
Lesson 3. We want to measure more and more
Our what is “building great teams that allow companies to grow”. We want to do this by identifying, selecting and developing the right people based on data.
We, as well as our customers, have tons of great ideas on how to do this. Though, we cannot do everything at the same time and not every hypothesis is proven to be true in the end.
We focus on making as many things measurable using the resources that we now have. Sometimes we simply do not have the time, like with launching our new product Team Analytics, when COVID-19 started, forcing us to slightly pivot our product. There simply wasn’t enough time to collect quantitative data. So, we used a more qualitative approach.
Making sure that we know how customers interact with our product, which parts of the product are performing well and which aren’t, which churn reasons are most important, which buying reasons are most important, which bugs occur most are all examples of things we can measure fairly easily.
Knowing these things will make it easier for us to discuss what we want to build for our customers. It also increases understanding within the company on why certain things are picked-up where other things are not. Lastly, we can also use this information to inform you as a customer on why we are doing what we are doing.
To conclude, I genuinely believe that we are on the right track (let’s measure this ;)).
Are you a customer and do you have any feedback? I would be more than happy to talk to you. Please feel free to reach out to: firstname.lastname@example.org.