Product Management Handbook: 1 – Introduction

The intention of this handbook is to provide insights from 5 years of Product Management at Runtastic

Where I come from…

Almost 6 years ago, I was given an incredible opportunity by Florian Gschwandtner, CEO and Co-Founder of Runtastic. I had just finished my first master degree in Digital Arts, besides working part time as a 3D artist at the company. At that point, I had 0 experience with professional product/project management in the software industry. My interest only came from organizing and leading student projects and taking some Coursera classes on the topic.

Naively I asked Florian, if I could become a Product Manager at Runtastic and he gave me that chance. I will be grateful forever. (Sidenote: Florian just published his book “So läuft startup" [DE only] – check it out here)

This was the start of some quite intense years – I was learning everything from scratch: SCRUM, design thinking, user stories, roadmap planning, marketing, editing, large scale CRM, analytics,… you name it. I saw the company grow from 50 to 250 employees, 2 acquisitions (Axel Springer & adidas), 90+ million downloads, 20+ million active users on a yearly basis. I was giving talks at Google in London, Apple in Munich and at the Mobilize conference in San Francisco. 

After 5 years in the job I left Runtastic this summer for a new & different challenge of building the Mindbreeze office in Chicago. Still, Product Management will be in my heart forever and I want to share what I consider my product management secrets and provide my personal perspective on the job.

Product Managers at Runtastic

First of all, let me try to explain, what I consider a Product Manager specifically. There are many PM jobs out there and probably each one is a little different. Also, during my own career at Runtastic the role changed tremendously as responsibilities grew more complex, processes and the requirements evolved and the team and me became more proficient with our responsibilities.

Starting up small

When I started, the company had 3 major development departments: Android, iOS and backend. Each of those had their own SCRUM process going on, so the main responsibility of a Product Manager was not just writing good user stories but making sure everything got implemented similarly to the other platforms. Probably, everybody with a little experience will already facepalm at that point, but this is how a lot of startups start: rudimentary and lightweight processes that evolve organically.

Scaling development

At around 150 people, a more formalized agile framework was introduced, based on the Spotify model. Teams would be set up cross-functionally, so that they could be trusted with end-to-end shipping responsibility of the product. Team members would include iOS and Android developers, QA engineers, designers, backend engineers, a SCRUM master, and a Product Owner. 

The meeting structure got fomalized with story writing workshops, backlog groomings, retrospectives, and demo sessions. A Product Manager didn‘t need to discuss specifications with 3 teams but only one, with all team members in the room. A big step forward.

Further, the PO and PM roles were split up. Product Owners were essentially leading the product development/SCRUM process while Product Managers were responsible for the product roadmap. This included planning new features, strategic investments as well as evaluating results & outcomes.

Change management pain

On a side note, those transitions are almost always painful in some ways. At Runtastic it was planned extensively and very well (kudos, Stefan & Tom). The pain came with a shortage of personal to fulfill all the new roles and the holistic understanding of the SCRUM framework throughout the company.

For example, I was fulfilling two PO roles and a PM role for a few months, which was probably the most exhausting period of my career so far. Still, the learnings were massive and I wouldn’t want to miss that period.

Probably the biggest challenge for transitions like this is, that everyone from top down has to have the same understanding of the desired structure. This includes decision making, organization, and responsibilities. That understanding can become a huge obstacle if top management is too disconnected from the actual development processes.

Focus of this Product Management Handbook

However, in this series of articles I will write about the role from a higher meta level. It‘s more about guiding principles and ideas rather than a Product Management manual. I think, it will benefit not only product managers, but might also give insights to those working in different departments and jobs.

The idea is to give an overview of the dimensions that product management exists in. The reader should get an overall understanding of all the factors around digital product management, so we will start with the basics next week.

Questions, ideas or feedback? Would you like to read on a special topic? Leave a comment or shoot me a message!