I spoke with Tommi Forsström who’s the VP of Product at Teachable.

He’s had a very interesting career having been heavily involved in music journalism, engineering, and now product. He’s also a big proponent of the agile methodology, which is something we spoke about.

Tell me about the early days of your career: you studied engineering, worked in music, and seem to have tried a lot of different things!

I had no interest in a career in tech in my early twenties.

In fact, working with computers or in tech back then (in the 90s) was a really fringe job. It was no one’s dream unlike now.

I had a super unsexy aspiration back then: I thought I wanted to become a math teacher. I went to college and my degree was basically supposed to crank out math teachers. I also had to have a minor and I picked Computer Science because I had been messing around with computers from a young age.

At the same time, I was a musician. I was this snotty, elitist, independent minded musician who stuck my middle finger to the establishment. I was in a band and we had started self-releasing albums with my friends.

The web was also becoming a thing that people use at this time - so I was like how do I make a website. And then next thing I know, computers became a means to an end for me. It was about asking questions like “How do I make my band have an online presence?” and just finding out how to do that.

So the internet started to play a bigger role in my life - I started to help my friends’ dads with their computers, I had a side hustle selling CD-Roms, and I was basically doing a bunch of this stuff in my free time.

And then the dotcom bubble hit! Since at this stage I knew a bit of code, I got a coding job because it payed really well. But still, I was very much invested in music.

What was the point of the day job? Why not just go 100% in on music?

If you were a programmer back then (late 1990s, early 2000s), you could basically pick where you wanted to work and get paid really well. I could dictate my work schedule (for ex, I could say I wanted to work four days a week) and I could even just be like “Hey, I’m going to be away for 6 weeks because I need to go on tour”.

So since I had all these benefits, I was sucked into this tech career. I mean, what 20 year old doesn’t want good pay and freedom?

Fast forward 5 years, I was now working for this major Finnish publishing company. I was cranking out magazine websites, different content management systems, forums etc.

And this is when I came to the realization that I’m actually starting to enjoy this day job.

It’s no longer just this way for me to enable this other side of my life - it’s something I actually like. At the same time, I was getting older and was starting to question whether music was going to pay my bills long term.

Around what time did you get introduced to Product Management?

I moved to NYC in 2012 to be the CTO of an early stage startup. And this was around the time the wave of product started to hit.

So when I actually started to look at the job description for a product manager, I realized it was all the things I loved about my job! This is when I first thought to myself that this might be something I should transition into.

So for the next few years, I basically transitioned from being an engineering manager to being a product manager.

Because of my engineering background, I had this myopia where I looked at all product problems through the lens of my engineering experiences. And so I thought if I get the process and execution right, it’ll all be fine - I didn’t know anything about strategy or go-to market or business or sales - none of that. I just thought that if I get the technical implementation process right, it'll all be good.

I obviously had a lot of things to learn. But that’s how I got started in product.

Do you think part of the reason you liked the Product Management field so much is because of the entrepreneurial nature you developed at the beginning of your career through music?

Yeah, absolutely. I would not be where I am today without that experience of running a label, being in a band, running a brick & mortar store. Promoting tours and shows, managing people - these are all skills that were transferable and I learnt them at a very young age.

For example, in 1997, when I wanted to release a CD single of my band. I didn’t know how to do that - I had to ask people and figure out. I had to download a copy of Adobe Illustrator, try and make a file that you can send to the printing press, and boom - next thing you know you have a CD!

This relates to the fact that the vast majority of what I do in my career has nothing to do with how smart I am or how good my credentials are. It’s actually mostly about being scrappy and comfortable with figuring things out, just like I did back in 1997.

That’s really cool. What would you say is the biggest thing that surprised you about building a career in Product Management?

I hinted at this earlier, but yeah, I was unaware of how much my existing strengths in engineering would work against me and how there was lots of value in building on the weaknesses I already had.

If I were to do my engineering to product transition all over again, I would pick up books and read blogs on how different business teams work and I would try to reach out to different stakeholders at my current company (like the CFO or the VP of Marketing) so that I can expand the boundaries of what I see.

I was really surprised to find out how truly cross-functional product management is. You can never ever afford to build a bubble or limit your field of vision - that is going to really kill your advancement.

Another thing, as I got more senior, was that there is a limit to how far functional excellence can get you. Meaning that generally, once people start climbing the ladder and getting better at what they do, usually early on it’s fuelled by doing the thing they do. Whether that be engineering or product management or whatever.

But what nobody told me was that the higher you go, your job essentially boils down to capital allocation. It’s a numbers job - it’s no longer just about being good at product or engineering (i.e functional excellence), it’s about being able to speak the language of business and understanding what needs to be done to move the company forward.

You’re a big proponent of the agile methodology in product management. How would you describe it to someone new in their career and what is its biggest benefit?

First up, I’d say that context is important. I’m a software product person - most of the products I’m in charge of shipping are cloud hosted and it’s pretty easy to make changes. If on the other hand, what you build has to be manufactured somewhere across the world, then being too agile is probably going to cost you a lot of money.

So in the world of software products, where changing things frequently is possible, the main reason you want to defer decisions to as late as they can responsibly be made, is because every passing second is a learning opportunity.

Sometimes it’s the nice kind, where you’re able to discover something pleasant and new. Other times, it’s really frustrating and the kind where an engineer comes to you and lets you know that the codebase is melting down or your servers are on fire.

But regardless, in both cases, you learn something.

The vast majority of what I do in my career has nothing to do with how smart I am or how good my credentials are. It’s actually mostly about being scrappy and comfortable with figuring things out, just like I did back in 1997. Tommi Forsström

So for me, true agility is the ability to take in information - whether that be customer feedback, business content, competitor analysis, pleasant or unpleasant learnings about your product, etc - and if your systems are properly set up to absorb that information, you will be better off.

Okay, and what’s a common mistake people make with Agile?

I’d say the biggest one is thinking that there’s a different outcome they’re going to get from it. People who switch from Scrum to Agile think they’re going to ship things much faster. And in that case, if that’s what you think, you’re not playing the game for the right reason.

You’ll probably get to good outcomes faster, but that might come in the form of shipping less features (because you realized a lot of them were unimportant).

The core takeaway of Agile is adapting to change. Making decisions when they count the most and when you’re best equipped to make them: as late as possible.

So it’s not about just running faster, but rather about walking a shorter distance and prioritizing more effectively.

Let’s wrap it up by talking a bit about Teachable. What do you like about working there, and what kind of product culture have you guys built?

I’m definitely very passionate about empowering small businesses and helping creators make a living from their work. I’ve worked with a number of companies like that - for instance, I was at Shutterstock helping people license assets from creatives. I was also at a company called Splice doing something similar.

But what excites me about Teachable is that the scale of empowering creators and that level of enablement is much bigger than anything I’ve ever experienced before. Just two days ago, for example, we hit over a billion dollars in total payouts to our creators.

So just the fact we’re putting so much money in our creators’ pockets gets me through bad days or periods when I’m unmotivated.

In regards to your second question: my main job is to focus on leading our product development team from an executive position. So I need to connect the dots between what the board needs to hear, what the executive team needs to hear, what goes into our profit & loss statement, and how that correlates with what we’re actually building.

Finally, when it comes to product culture, I’m a big believer that any team that tries to place either engineering or design or data above the others is probably going to fail. That’s because “who should call the shots” is always context driven and decision making should be based on what benefits the aggregate, not necessarily just one vertical.