Streamlining Operations with product Led teams - An interview with Metigy CTO Johnson Lin

Peter Tylee 8 Jun 2021

Share:

I was able to sit down with the Chief Technical Officer and co-founder of Metigy, Johnson Lin, who shared with us some insights into product-led growth, and how it can transform and empower your teams when moving towards an outcome-based approach to product development.

 

 

So, can you tell us what you do at Metigy?

<u>JL:</u> Metigy is a platform that helps SMB customers improve their performance in digital marketing. We help people improve their performance by X percent every one to three months, incrementally, by having mechanisms such as insights, recommendations, and decision support. We also provide embedded data, giving them options and presenting data
alongside it, so they can decide what they want to do.

 
 

I like it. What’s the most exciting thing that you’re doing at the moment?

<u>JL:</u> This next phase, which we’ve called main systems. The idea is that we have all these different domain systems, and once we’ve completed the project, the data and insights we can present to the user will be so valuable and just in time. That gets us really excited in the team.

An example might be, if you want to pick an audience for a very specific purpose – to market blue shoes, for example – then you pick the location and it will give you an audience suggestion based on historical performance for what has worked when selling blue shoes in the past, you know, ranked by order and the bidding price. We were aware that a lot of businesses don’t have data from the past, so we have other ways of using industry averages or industry top-performing audience lookalikes to give you a quick start if you’re just beginning your own e-commerce store and have no idea what to do.

 

When you think about what you’re working on, what’s your biggest challenge at the moment?

<u>JL</u>: Having a very clear grasp of how to get to the end, because depending on how you lay it out, the solution you build can vary completely. The challenge to make those changes, I feel, becomes incrementally harder as your team grows, because there’s loss of knowledge transfer.
You can’t be doing everything yourself. Naturally the person that started the codebase might be able to do it in one or two weeks. But then someone that came in the second or third phase of hiring may end up taking four weeks because they’re worried about breaking stuff.

 

That’s been my experience as well. Do you have a strategy for managing that process?

<u>JL</u>: We are currently transitioning to a product-led growth methodology. It’s basically a mindset to have the team be more product-minded, working towards business outcomes, not delivering features on deadlines. For example, if your initial goal was to increase user retention by 20%, and you hit that deadline, if it doesn’t increase their retention by 20%, then you have not achieved anything.

A big driver for that is we are currently in a phase of getting the next round of funding, and we’ll look to grow our team quite a bit. So naturally, we can’t manage every detail. David and I are looking to transition the teams to be more semi-autonomous, and hopefully autonomous, where you’re not giving them instructions on what to do and checking progress; they have clarity on where the business wants to be, and what the business wants as an outcome.They have enough clarity and resources to work independently. Instead of us managing them, they’re just periodically reporting on progress.

It’s a very different kind of managing, a big transition. We are beginning the process now, but I don’t expect results for another three to six months, because it’s a very new mindset. And we’ve got to get everyone on board and aligned, so it’s going to take some time. If we expect to grow 3x or 4x, there are going to be a lot of new people, so that will bring more challenges. We’ll see how that goes.

 

It sounds similar to the philosophy of moving decisions closer to where the information is. The closer the decision is made to the information; the more efficient everything becomes.

<u>JL</u>: That’s exactly right. As an example, we might have a product idea that we imagine will be useful to users. It starts as a high-level vision, but we don’t know what APIs or external data we can get. It’s the people closer to building it that know all that. In the past, we’d say, “We’re trying to build this feature set, and you have to build it exactly like this.” And it usually turns out to be a subset of that, because we don’t know what’s possible, we’re just imagining possibilities.

We are now thinking of moving towards an outcome-based approach, which means the solution is not fixed. When the engineering team knows they’re trying to get to a particular place, they’re empowered to do more digging and understand the capabilities and come up with ways it could work. Team product ownership pushes the business outcome closer to the team, and empowers them with the ability to come up with solutions. In return people feel like they’re involved, that they own this idea, and are therefore more autonomous and more rewarded.

 

What would you recommend to people who are trying to bring innovation to their own organisations?

<u>JL</u>: You need to set a culture of trust. Because the teams that are building the product need to feel that they are trusted and empowered to try things and not be punished every time they make a mistake. Because if the teams are always locked down to deliver a certain thing a certain way, then that in itself is fixed. And if it’s fixed, how can it be innovative?

I think part of the innovation is experimentation, so you’ve got to foster a culture and environment that helps the teams to experiment. But obviously that experimentation has to be in a way that allows them to experiment quickly to find the biggest insights. You don’t want to be spending weeks and weeks experimenting. You want to try and see if there are ways to do it in a shorter time frame, hours or days at most. If you’re unsure whether a certain feature is going to work, why would you spend two weeks building it? Experiment to see this demand first.

 

Is there any advice that you would give someone in their early 20s that wanted to become a technology leader?

<u>JL:</u> If they know they want to be in tech, then what’s important is finding a good company where they have good tech and a good mentor, because whether a person is able to quickly grow completely depends on the person managing them. How much trust are they given? What are they exposed to? Are they working on popular tech that everyone is working on? You don’t want to be in a company building HTML templates for three years – that’s not going to help you very much.

 

A big thank you to Johnson and the team at Metigy for their time, Visit the website at <u>Metigy.com</u>

 

Subscribe to the GistLens Technology Review at gistlens.com/magazine (or scan the QR code) to read an extended version of this interview

Interview

Share:

Written by

Peter Tylee

Call us

+61 2 4063 1115

Email us

info@gistlens.com

LinkedIn

Connect with us

© 2021 GistLens Pty Ltd.   ABN: 85 632 037 024.

We help turn big ideas into beautiful digital products and experiences.

GistLens