Product in Practice #1: Aidn with Marius Røstad (CPO)
Marius Røstad (CPO) on company rhythms to go from 0 to 1, OKRs for product teams, the importance of product trios, flexibility as a competitive advantage, PMs and viability risk, and more.
👋 Hey there! I’m Afonso, founder of Scandinavian Product Group.
Every week-ish I dive into a new organization to show you a bit of Product in Practice around Scandinavia (and beyond).
If I’m not sharing with you the ins and outs of how certain organizations do Product, I’m sharing my own thoughts on specific topics - usually going on a rant accompanied by a rough sketch.
So, regardless: you’ll hear from me. Consider becoming a free subscriber so you don’t miss out!
Today’s deep dive is about Aidn - a really interesting Norwegian tech company, with a very inspiring mission. Aidn has grown from 15 to 100 people, picking up some of the greatest talents in Norway over the last year and a half. The company is working to solve some of the biggest problems in healthcare.
To give us a tour of how Aidn builds products, we got none other than Marius Røstad, Chief Product Officer (CPO) at Aidn. Marius is a great product mind with lots of gems to share with the community. He used to head up product at Ruter, and is responsible for Norway's only Product Management survey.
You’re in for a treat. Let’s dive in.
Product in Practice #1: Aidn
1. Tell me a little bit about Aidn and the problem it’s trying to solve.
Healthcare services in Norway and other developed countries face an incredible growth in people needing care and help. There will never be enough healthcare personnel or institutions to take care of everyone. The healthcare service will grind to a halt if municipalities don’t get new tools or processes. At the same time, we know that information doesn’t flow between different parts of the health care service. This often leaves patients and next of kin in vulnerable situations, where they become responsible for sharing their medical information.
Aidn is set up as a corporate venture in Norway’s largest eHealth group, Kernel, to solve these and other related problems. The product we’re building is a core system for municipal healthcare, letting municipalities switch out their extremely outdated systems. This will solve their fundamental problems and give them a platform that lets us and them innovate.
We started working on this in the fall of 2021 and although we’re around 100 people working on solving these challenges we’re still not in the market yet, which poses some interesting product challenges. Our main target is however to move from pilots to paying customers this year, and have our first viable version of our product this summer. We’ve however been piloting parts of our product in about 20 different municipalities in Norway over the last two years. This has been critical for us in the phase we’re in.
2. How do you approach planning?
The fact that we have an organization of about 100 people and no customers is really important in the context of planning. We’re in that 0 to 1 phase of building product. That has a great impact on planning and goals. Because it’s not like our business goal at the moment to increase revenue or expand into new markets. It’s getting that first customer.
“Why the f... do you have 100 people working on this if you don’t even have product market fit?”, you might ask. That’s a fair question, and if I should try to explain, it goes into the specifics of the market we’re entering. We have extensive insights and research into the problems we’re solving, the systems they currently have, and the market dynamics. Given this, our owners have great belief in our ability to solve it and to reach product market fit.
As mentioned, we’re building core systems for municipal healthcare that let them switch out their existing systems. To do that we need to solve a lot of the needs that are currently being solved in those products. These are products being used by 200 000 health care workers helping 400 000 patients. That means we need to build a lot of features to let a municipality switch out their current systems. Which means we’re in a heavy building phase at the moment. For us, it is all about figuring out where we need to just have parity with what they have today or where we have to innovate to go 10x.
All signals point to this being a good strategy at the moment. However, it makes planning difficult.
We’re currently in the middle of planning and OKR season. This is a super exciting time, as it fosters so many good conversations. The planning period is for the next six months, although we always have a view towards the next year and a half.
It all started with the C-suite setting company goals, through workshops, discussions with others, and several iterations.
Then they were presented to the whole company during Town Hall. This was the kick-off for all the teams and departments to start working on their OKRs leading up to the company ones.
Below are the actual company OKRs for this period.
We only have one objective, with four key results.
And I think this is where we shine as a company, compared to other places I’ve worked in before.
Since day one we’ve been really good at setting clear goals - aligning everyone throughout the company on the one super important thing.
One key takeaway from this process is the need to detail out the objective and the key results. There are so many potential interpretations, so it’s critical to be super clear.
From the first KR, what does 85 percent actually mean? And the same with Defined Pilot Munis and Use Aidn as Their Main Tool. Defining this is all about being clear about strategy!
This is the first time we’re doing company-wide planning, and we’ve been through several iterations to get it right. Not sure we’re getting it right this time either, but we’re much further. And from looking at our company OKR, it’s very encouraging to see how all the key results involve several departments. None can be achieved by one department alone.
3. I was going to ask if you use OKRs at a company level, so I guess you’re tapping into that already. Tell me more.
Yes, as you can see, we do use OKRs - but I’ve got to say that I really don’t care about the framework itself…
I’m really passionate about having measurable goals. We have 10 teams in product and tech, and we all must know what we’re trying to achieve and how well we’re doing.
OKRs is a fairly decent framework for that.
However, there is a danger that people get too caught up in the framework. I’ve been guilty about that myself earlier, but I’m much more concerned these days about people committing to a certain goal and measuring the progress towards that goal. I have relaxed a lot about what you call it or how you actually do it.
There have been three major changes to planning this time:
1) Adjusting scope: At the same time as OKR-season, we’ve adjusted scope and responsibilities for most of the teams.
This is to ensure we’re set up for success. We try to have a good balance of teams continuously work on a problem and a flexibility of people and scope over time. Over the last year and a half we’ve had really stable teams, but to reach our goals we’ve had to make more adjustments going forward.
2) Planning week: At the end of OKR season we’ll hold a digital planning “week”. This is where we all get together to discuss across departments and company. We need to make sure people aren’t committing to anything that isn’t really important or that they actually can’t do. There will be dependencies across the company, and it is really important that all teams that are dependent on each other do commit to deliver on the same key result.
3) Accountability: We’re trying to make people more accountable for the key results that are set.
Each KR (key result) will have a DRI (directly responsible individual) that is accountable for it.
They will report on the progress of the KR in a cross company meeting once a month. The intention is to foster more visibility, alignment and accountability.
Those are the most relevant changes to our planning process.
4. Do you also use OKRs at a product team level?
Yes, all product teams in Aidn have had OKRs over the last couple of years, but we’ve been through some iterations. Especially regarding key results. We started out being super disciplined on user needs and outcomes. A major learning for us was that it is really hard to be strict on that in the phase we’re in, so we’ve become way more chill about it.
We do want to use outcomes where we can, but we’re also not worried if people put in delivery goals at the moment.
We’re in the 0 to 1 phase where we need to build a lot to get off the ground. That makes it impossible to be really strict on outcomes across 10 teams in different stages of product development.
It is much more important to me that a team knows what they’re doing, why they’re doing it, and are motivated by that mission - than being super strict on how we measure it.
Way too many people and “thought leaders” are being too strict about this. People need to relax more 😉
During the OKR season throughout January there are a couple of rituals we have set up to ensure we work together across levels, and to have strategic and operational viewpoints affect each other. John (our CTO) and I are continuously talking to all the teams. We try to help the teams out, with strategic context and focus.
To ensure that dependencies are discussed, the teams are required to self-organize - but will get help from leaders to identify them.
I feel really good about our OKR process this time. It seems to be going well. Already know a couple of things to improve for next time though!
5. I understand you haven’t launched officially yet and are currently running pilots. But, overall, how’s your product development process?
Because of the phase we’re in, it has basically been a lot of autonomous teams running their own processes.
But this has also been easy for us because of all the really talented people in product, design and engineering. The teams have been really good at this themselves.
We are however planning on putting a bit more structure into the development process over the next year. We need to get better at aligning on the different problems to solve, reviewing the potential solutions and coordinating our launches.
Then we also need to be ready to evaluate how our launches performed. We’re developing a really interesting framework for this that I’d love to share later on!
6. How's Aidn organized to build products?
Aidn has always been super focused on aligning Product and Tech.
That has been a core founding principle for John and I, since we started almost two years ago.
On the first day of working together, we outlined our vision for the org, and one of the principles we established was that we wanted trios to collaborate across the different levels. This has been really important to us. We’ve been through different stages of growth, where we’ve been more or less successful in this, but I feel that over the last couple of months we’ve really gotten good at it.
We have 10 product teams, where two are strictly internal.
All the teams have a product trio of Product Manager, Tech Lead and Product Design Lead, except for the two internal ones.
The infrastructure team and the design system team have their own setup.
All the 8 other product teams have one or more designers. They all have between 3-6 engineers.
And all the teams collaborate with health care personnel, either inside Aidn or with people in the municipalities.
We also have a product operations team that works on enabling the teams and making sure the company has all the data and insights they need.
It was one of the first steps I took after joining Aidn to get a product operations team going - to help us scale better. We knew we had to scale the organisation fast and that we needed to let the teams focus on building products, not on processes.
This team is core to how we run most of our cross-team processes, and to ensure teams are data-driven and do research in the right manner. They’re also crucial in ensuring we have the insights we need for strategic planning.
In addition to these teams, we also have a director level.
We have four directors in product and design, and we have three directors in tech. They are basically forming their own trios... Having them work closely together is just as important as getting the trio in the teams to work together.
For our CTO and myself, it has been important to set up our own rituals with all the teams and all the directors, to ensure we all can influence and collaborate.
The two of us have bi-monthly meetings with all the teams, and we have bi-weekly meetings with all the directors. This is a key success factor in getting more alignment and collaboration in our product and tech organisation.
We have iterated on this structure as well. When we started we did think there were four distinct domains to our complete product offering:
Citizens
Clinical personnel
Administrative personnel
Core platform.
We have discovered that this didn’t make as much sense as we originally thought, and we will be making some changes to this.
The key takeaway is that it is impossible to think through everything, so we need to be flexible. We’re iterating just as much on process and org as we’re doing in product.
I think it might also be interesting to look at our rhythm and rituals in product and tech.
We have two six-month periods of planning aligned with the broader company, and two-week development cycles where everyone kicks off at the same time, with planned user interactions, discipline syncs, and end-of-cycle retros and show and tells.
7. How many PMs and Designers do you have?
In the product organization, we’re around 35 people, while tech is about 45. Product consists of product and design and product operations. We currently have 9 product managers and 18 designers at different levels. In addition we have 4 directors across product and design.
8. Aidn is already known in the community for its strong Design culture. How do your teams approach product discovery together?
The most important thing for me is to get that trio to be working closely together when we do discovery.
It is not only product and design that should do discovery. Tech has to be involved as well. They all bring different perspectives and those are all important.
That doesn’t mean they should do everything together, like they were joined at the hip, but they have to be responsible for the totality together.
But this is a difficult topic because we have many different teams with different people and of different sizes. And it doesn’t always make as much sense with that model. So again, we’re flexible. If the team gets it to work, and they actually solve the problems they’re trying to solve, we don’t care too much about how they work. In general, we try to have the least amount of process we can, while still ensuring we have a responsibility across all the teams.
One thing I do want to mention when talking about discovery is that I think the different disciplines bleed a bit too much into each other. One of my main challenges about product management in Norway over the last year has been that Product doesn’t look enough into viability.
It has been much more focused on only user needs. I’m not saying they shouldn’t focus on that, but if our customers are not willing to pay for that user need, why should we solve it?
I think viability has to be a much bigger part of discovery going forward.
Our teams also have a lot of strong design talent, so user focus will naturally be ingrained in the team, so PMs should have ample time to also work with viability.
We’ve tried to put that front and center, with us making sure that we can actually quantify the effect our customer get from our product. The critical part for municipal health care is that we save them time, while keeping or increasing the quality. That will allow them to solve their major crisis. All teams need to quantify this going forward. We’re currently working on a framework connecting the product work to actual quantifiable benefits the customers are getting that is really forward-thinking. I think this will be one of our key differentiators going forward.
9. If you had to pick one, what's been the biggest challenge for your org in recent times regarding product development?
I think the challenge of building a 0 to 1 product with a large company like ours is the main challenge.
80 people in our product and tech organization without a paying customer is a challenge. We’re building a large product org that should be best in class, but with no paying customers, we don’t have thousands of users to get signals from.
We do have pilot municipalities using parts of Aidn. That is also something we’re scaling now over the next six months. But we need critical mass in the product to make sure they’re able to stop using their existing systems. That means we’re building a lot of features that we know they need.
To be in that building phase for a long time without a lot of signals is difficult for a lot of product teams. Basically, we’d have been working for three years before we get that first official customer - if we reach our goals. That is a long time to be in this phase. And it’s something we’re very aware and conscious about.
10. Anything you wanna leave us with, wanna promote or you want the community to know?
Well, for anyone reading all the way to the bottom of this post, hats off, and I hope this was in some way useful.
I definitely have a couple of things on my mind.
Aidn is hiring Product Designers, so please reach out if you know someone
I'm planning a little gathering of product leaders, together with you Afonso, which should be a great thing. For product leaders who think this could be interesting and relevant, please spare three minutes to answer this little survey we’ve put together - so we hit the right level.
On the topic of surveys, I’m planning the 2nd Product Management Survey in Norway, but could always use a few extra hands to help out. Anyone interested, hit me up on LinkedIn 🫵🏻
And one more thing! I love meeting new people who are passionate about Product, so reach out to meet up for coffee ☕️
Thank you for reading!
Who’s next? 👀
I’m looking forward to sharing with you soon the next Product in Practice deep dive. My next guest is the amazing Christoffer Bølum, Head of Product and Design at Ruter. Make sure you don’t miss out!
What would you like to learn? 🙌
I’m already in touch with 10+ other great product leaders to tell their stories - and I can’t wait to share them with you.
What would you like to know more about? Help me make this newsletter better.