Starting in Product in a new company — #3 — Implementing tools & ways of working early

This series of articles tells the story of my first 3 months as Chief Product Officer at Vapaus & how I dealt with discovering totally new colleagues & challenges. Missed the previous episodes? Read #1 — Talking to people & #2 — Drawing stuff

I’m expecting this article to be a lot more controversial than the previous two. Which is why it’s also substantially longer. 🐢

I’ve professionally grown up with “Agile” and people religiously following its principles. In the world of tech, there’s the school of “If X, Y and Z have been successful doing it, why shouldn’t we do the same?” and the school of “Nah, every case is different. Let’s read about their story, get the essence of it, then build our own”.

I’m a Nah person. I love a lot of things about Agile, but then again I hate it. I also love a lot of things from other frameworks and experiences I’ve had or heard about. One thing I do firmly believe though, is that confidently implementing ways of working makes and will continue making my life in Product much easier.

Confidently implementing common ways of working makes life easier in any context

It all started with a mistake

In my previous job at Virta, I became the first Product Manager, and then transitioned to becoming to first Product Owner of our growing tech team. In that role, I was responsible for the development of our big platform renewal project. It was a literal jump into the shark tank as I had very little knowledge of anything tech- or design-related, and had to learn everything on the spot. And quickly. It was awesome.

Fast forward to 6 months into this project when we restructured our Technology unit to be divided into several products (vs previously more project-based teams). To support this change and fast growth, we also hired several other POs.

Because of my experience in the company, I was asked to “lead the group”. And whilst I think I did a pretty good job at keeping the communication open, I failed at at least one important thing in my eyes: implementing Productboard*. I’m not even sure everyone even took the time to register and look around. 😊

*As a side note, we did start actively using the tool later on, but that was not my own success story

Why are tools important early on?

So why did I fail so badly? There are probably many reasons, one of which being my inexperience as a leader. But still: I was there, I did the job, I helped, I explained all the benefits of the tool. I even basically committed to doing most of the work myself, if provided with the right data. So what went wrong?

I did everything right (or so I thought). So why did I fail so badly?

My colleagues then gave me two main reasons why not to use Productboard:

• Management prefers PowerPoints
• It’s additional work I don’t have time for

And they were right, too!

Whilst those are reasonable points, they can be easily put under one bigger human problem: people hate change. Not just the experienced POs who were giving me these arguments, but everyone around them and us. Very few people I know are actually happy and/or interested in learning about new ways of working, if the ways they are using now are “good enough”. It’s a lot easier to motivate anyone to go from 5% efficiency to 30% than from 60% to 85%.

Now, Vapaus is a really small company at the moment compared to Virta at the time I screwed up my implementation. It’s still depending on a lot of manual work. People need help now. And people who need help now are a lot likelier to A) be open to change and B) be appreciative of the person who’ll guide them through it and “do the work”.

It’s the perfect time to jump on the train. Or the bike.

Tools we chose for Vapaus

Vapaus was not riding naked when I started. They already had started using important collaboration tools like Slack, HubSpot, Trello etc. But little had been done on the Product & Design side, which is where I decided to put my early focus on. I’ll be telling a bit about the 3 I spend the most time on and why they were a good early pick.

• Miro

By now you probably don’t need an introduction to Miro anymore, but I won’t risk it: Miro is a collaborative whiteboard, which got super popular during Covid times as it effectively replaced the actual physical meeting room whiteboard we didn’t have access to anymore.

Miro is our second-most used collaboration tool — after Slack

But it’s not just a meeting facilitation tool. Miro is also the place where I paste all my brainstorming ideas, it’s sometimes where I create beautiful process drawings to paste into PowerPoints, it’s also the place we document our successes… I use it for prototyping as well, when I’m too lazy to take the time for Figma. We even tried using it as a Knowledge base. That one did not work out so well. 😊

This stunt was made by professionals, don’t try it at home

Today everyone in the company has at least attended one Miro workshop, and most teams have at least one board they regularly use. It’s practically our main collaboration tool — after Slack. And since boards are public by default (even if it’s possible to modify that parameter), it means that everyone can also look at any time, asynchronously, at the work others have been focusing on.

It’s good to note that some Vapaus people had been using Miro before — so it also didn’t appear as if I had pulled it out of a hat. It was therefore not a complete discovery for most, but something we decided to make accessible to all and really mainstream when I joined.

Pro-tip: take a minute to make a nice cover picture for your boards! We use one colour per team, making it super easy to find the ones we need.

• Productboard

Yes I did it again! But this time no one tried to discourage me (pro-tip: be a team of 1 so you don’t have to ask people’s opinions!). 🥸

Productboard is a Product management tool (who would have guessed?) with very powerful features. It gets very pricey as you start needing upgrades, but that’s not a concern of ours at the moment: we need the basics.

I use Productboard for three main reasons: figuring out what our product is and what it should be, communicating with internal & external stakeholders (using the roadmaps & community portal), and the most important one — gathering and analysing feedback and ideas.

If you don’t store your qualitative data when you receive it, it’s lost.

It is the most important one at this point in time because data like that does neither grow on trees, nor come back knocking the day you need. I see it as the most crucial part of my job currently to make sure that every voice is heard so that I get the whole context I’m working with.

A fantastic example of useful feedback

• Confluence

This one will probably sound funny. Confluence is often seen as a huge machine, not really suitable for small teams. Well guess what? I love Confluence!

I could have started my product and technical documentation elsewhere. Initially, I had written very long Google Docs and stored them in the Drive void for people to see. But I missed Confluence. And coincidentally, it’s free up to 10 users.

So no, I will not try making the case that Confluence is the best place for a start-up to store their documentation. But it works for me and our small development team. And the day we get new people in, they already have a rich documentation to work with easily, instead of getting a bunch of links to hidden folders.

Ways of working

If you want someone to do something, make it more interesting for them to do it rather than not.

Ways of working are what makes or breaks the implementation and daily usage of tools. They need to be shared — not necessarily by the whole company, but by all collaborating around a single topic and/or on the same tools.

There are two things I’ve been asking a lot since I started:

• Did you document it? (or its early variation: is it documented?)
• Can you push it to Productboard with a comment?

And it works! Up to today, we’ve already received 120+ insights on Productboard, and we have our own Knowledge base where all questions are now regularly documented. Ways of working work when they are easy and don’t require you to think about them.

• Documenting has been made easier by working on a baseline everyone can contribute to
• Productboard’s usage has been greatly simplified by integrating it to Slack, forms & email channels

If you want someone to do something, make it more interesting for them to do it rather than not. A first example of this, using Productboard again: clicking on two buttons is a small price to pay to make your idea heard, possibly considered for development and finally done — by someone else — making your own life easier. A second example has been the integration of our Technology Trello to Slack: it used to be a pain to go and look at what had been happening — now all the important changes pop up in our channel for everyone to see.

Mistakes to avoid: where to draw the line?

Starting in a new company is super exciting. At least I find it super exciting. So much to learn, so many new problems to solve… One manager once told me “You can’t save everyone”, which I suppose summarises pretty well the situation I tend to put myself in after a few months.

Overexcited people often don’t match the “mood” everyone else has around them. Because they’ve been here longer, they understand the context better and are a lot more realistic regarding what can and should be done.

For this reason, it’s also important to be a bit careful and not to try to change everything at once. Remember: people hate change.

What is a bad tool to implement early?

A good tool is a tool that, over its lifetime in your company, will end up saving more money (=hours, turnover) than it costs. But honestly, using only this framework, you’ll find that most tools are good tools if you use them well.

The keyword here is time. ⏰

• Is it the right time for this tool?
• Do you have enough time now to implement it well?
• Will you regularly have time to use and maintain it?

I can give a couple of examples of tools that I chose not to implement yet:

Jira, like Confluence, has been my lifeline. I love it. It’s great. But not everyone agrees with me 🤷‍♀️. Still, I would be ready to put the time and effort to implement it for our team… but everyone else here uses Trello. In essence, by simplifying my life (and, granted, providing more flexibility and scalability in the long run), I would have created artificial silos between my team and the rest of the company. It’s not the right time for Jira.

I’ve also been looking at a bunch of cool things I know I would love having and mastering as a PM like Maze, Screeb or WeWeb. For those who offered it, I even took the time to check out their platform. Unfortunately, I would neither have the time to implement them, nor to use and maintain them.

Like with everything else, you shouldn’t only look at the overall lifetime value and possibilities of something before you jump into it. It’s a question of prioritisation.

Should we get everyone on board?

No.

What is important is to communicate why these tools or practices are being implemented. To make their benefits visible. Eventually, people who need them will start using them.

I would however highly recommend to always find a chance to demo any new tool to the largest audience possible in your company so they know it exists the day they need to either use it or extract information from it.

It’s crucial to take the time to explain why we do/use something, and to make its benefits visible

I’ve also implemented a couple of tools just for myself like Figma. It’s listed in the company software list, and one day I hope I’ll share it with others. Today it’s more a playground for me test ideas rather than a design system. That’s OK too.

Jeremy if you read this: yes I’ve (almost) stopped using PowerPoint for mockups!

When the company grows

Obviously, again like for any other product or even personal decisions, you may (or rather will) outgrow the tools and ways of working you needed when you started out. And as the tool’s “owner” within the company, you’ll have two challenges to tackle: noticing it — everyone tends to love their own ideas — and leading the change.

Thankfully, this change should be much easier than if you had to start from scratch. Your team should already be familiar with the tools that are causing you issues and need changing. Find an ally to look for a replacement with you. Don’t try to impose anything that will be used by others. It probably seems obvious but it’s not: you don’t know better.

Cheers 👩🏻🎨

Any comments? Own opinions on the topics? Happy to hear & learn from them. ✌🏻

Read the next episode: #4 — Storing the knowledge