Eight responses to pressing product management matters in the startup world | Interview with Andre Albuquerque, One Month PM

The sphere of product building is a vast yet granular space to live in. Funny enough, we're all sharing this space for quite some time now, as we live in a world where 'building technology became a commodity, more accessible, cheaper, and easier than ever', as our today's guest says. With over 3,739 apps added to the Play Store every day in 2022, think of the billions adding up only for mobile apps. On top of this come all the other software products so many that are not even in the wide-audience public use.

This is why we invited Andre, founder of One Month PM, to share his take on what is important in building a new product today. Because, if we have the commodity of so many low or no-code tools, and the immersive deep tech enhancing reality:

'The one thing that isn't solved yet is how to translate people's needs into a decision process that builds products.'

Teodora Istrati, Linnify:

1. To start off, what do you think it's essential for a startup in its first phases, product management-wise?

Andre Albuquerque, One Month PM:

Okay, so I think a few things are very important. 

1. The number one thing is understanding the problem you're trying to solve, right? 

Starting up is like a scientific test. There's a hypothesis: people have a problem. 

The current way that that problem is being solved is either subpar, meaning there are better ways to solve it, or you believe you have an edge - advantage versus those who are trying to solve it. 

And you're going to test that by building something, by building a product, by building a value proposition. And then you're going to put it in people's hands. That's how you run your model, your tests, and the data, whether people use it and the feedback or not, and who's going to validate whether your hypothesis is correct or wrong. 

So I think that part is core when starting up, it's more important to spend time understanding the problem space, and what it involves regarding how people feel when they're looking or feeling or living through the problem. 

What are they using? Why are they choosing it? What's the value proposition that's catching them?  

2. The second thing is you need to create your canvas to really go deep into the problem and all the variables that influence the solution to that problem. 

What drives people to put the problem you're trying to solve towards the top of Maslow's pyramid, meaning it's less important at any stage of life because it's more of self-actualization, or lower on the pyramid, meaning it's more important for me now because it's more of a need?

You need to understand how people make decisions.

Where and when do people think about the problem? 

How do they act to solve it? 

Where do they go to search for a solution? 

What do they care about when searching for a solution? 

So a lot of this is about understanding, actually, people understanding - those who are prospective customers. Go deep into the problem space. All of that needs to happen to find the solution fit. 

The most common mistake people make is that they start with a solution because they have an idea. 

And then they try to carve their way into a problem space, which is already biassed by whatever you build. And very likely, either that problem you're trying to carve into doesn't exist, or the way you're trying to carve into the problem space is not the way that the people want it to be carved in. 

Yeah, so I'd say this is kind of the most important first step in starting products.

2. Products could meet higher success if they had a killer product management team? Can a product be judged by its product management style? What do you think of that?

A.A: I think it's really hard to see it from the outside. Because you never know what the teams are going through. Right? 

I think you can always say that every product could have been better, with better product management. 

You can also say that every product became big, every product that you know of, you know of it because of great product management, right? Because the thing is, you might only know about 0.0001% of every single product that has ever been built. So the findings, you know about a product means that probably they're very successful compared to the majority of the world. 

And that can be because our management was really well done. Or because maybe they didn't have product management, then that's a reason why they're successful. 

I mean, there's such a spectrum of possibilities.

I mean, there are indeed situations that feel it can be a strategic decision not to go for Product Development.

So a couple of examples: I’m aware there might be a bit of a contrarian view, but, like, take Twitter.

Twitter, could’ve easily replaced our phone numbers. But they didn't go that way. 

Was it because of Product Management failure? Maybe.

Was it a strategic decision that it makes sense? Maybe. 

Was it intended and then failed on the execution? Maybe. 

When they cloned Snapshot to the Instagram Stories concept - they were very successful. 

They're trying to clone TikTok with Reels, is that really successful?

Was that because of root cause Management? Maybe? Maybe not? I don't know. 

I mean, it's hard to see it from the outside.

3. Given your experience with decision-makers in product development, how do they see Product Management in terms of Product Success? Is it common for decision-makers to understand the potential effect that a Product Team creates?

A.A: I think it depends a lot depends on the company culture. 

The majority of startups only bring PMs when chaos is already installed. Right? Because initially, most of the time, founders are the PMs. They're the OG PMs. They're the ones who have envisioned it they drove all day. 

Maybe they're technical, therefore they know a bit of how products should be built more from the Building side of things rather than the Managing side and then they realize ‘Oh, I need more time for something else.’ 

The most typical thing is that PMs come in when chaos is installed, everything's burning, and the leadership & product need help. 

Other companies have had PMs since like ever, and they're used to having a ‘product organization’ now. I’m not saying it's a product-led organization, what I mean is that the Product mindset actually created an empowered view around how to build the product. 

Oftentimes, it's actually more of a Project Management type of team, even though they call themselves Product Owners and Product Managers. When it is, in fact, just a Project Manager. But again, that depends a lot on the organizational culture. 

The way I see it is: Product Management exists to remove barriers so that everyone can run faster.

Right? That's the role. And ideally, of course, point people in the right direction. 

When you do those two at the same time you get to a better place.

4. What would be your advice to decision-makers who are still not sure about Product Management? Especially to those who get to PMs when chaos is already installed. 

A.A: I think this is one of those situations where it's like kids, right? 

They need to 'put their hands on the stove and burn themselves so they understand they should not put their hands on the stove'. 

I could tell them ‘look, you don't know how much you're losing from not having properly structured product management with experienced people’. They usually won't understand and better off going like ‘no, no, no, no, I know, it's my product. I've been doing this. I know exactly what we need to do.’ 

But then they eventually come to a point where they do hire someone. They might even not even call it the Product Manager. They might even call it the GM (General Management). Be it whatever they might call it – that person is, in reality doing, some product management type of thing. Only then would they go like, ‘Wow, this is really empowering.’ 

I think they need to go through it to understand the power it brings in terms of time and focus.

Now, of course, there's another problem. The majority of PMs become PMs because they fall into the role. 

90% of the PMs generally are transitioned internally from a non-product role into a product role.

And when that happens, that person there doesn't know how to do ‘product’. And that's fine. 

That creates a bit more chaos, as it’s a steep learning curve there. So that kind of extends the skepticism of any leaders about the PM to go to 'This (unexperienced) person is the PM, but are they really helping?'.

It does make a big difference when you're able to hire a pm that has experience. But then again, that doesn't always happen.

You might need some enlightenment from the company leader to understand the big difference PM brings.

T.I, Linnify:

That's true, especially in startups, where people are prone to wearing multiple hats. That might be one of the reasons why things seem, and truthfully are, harder to accomplish at the beginning of the startup’s journey, yet:

5. Generally speaking, what frequent blockers stay in the way of product success?

A.A: Yeah, so I think there's the first one: 

1. So you have these two spaces: 

the problem space & the solution space

The problem space is about understanding what the problems look like, and respectively the solution space, understanding the solution that fits the problem looks like.

I think what gets in the way of success is a team that spends too much time on either. 

So it's too much time on the solution space, which is the most typical one is a team that doesn't understand the problem, space is going to build something that nobody wants, right? 

But a team that spends too much time on the problem space, it’s a team that doesn't ship. Someone else is delivering more and iteratively learning faster. Right? 

So teams that spend too much time on either side. This is anecdotal, I mean, it's my data, but generally, I correlate these teams to not learning fast enough. 

2. I think another thing is:

Teams that spread themselves thin & Products that get too niched

Spreading thin, meaning they try to go after every shiny little opportunity. Suddenly they're building a product that's way too broad, way too unfocused. 

You know, it’s like with those restaurants that kind of cook too many types of food, and they're not good at any. And this is a typical thing. 

You also have the opposite – products that go so deep into building stuff that's marginally required, that suddenly they don't have any results from adding more stuff. They’re missing out on opportunities, etc.  

So again, as main blockers, I think it's often about being on the extreme sides of the distribution curve. These two things, in my opinion, probably correlate with less successful products.

T.I, Linnify: In one of your posts, you talked about the ‘big four’: execution, productivity, scalability, and quality. 

6. Regardless of the nature of the product, what should the product team consider an essential set of thoughts as part of their mindset? Would you say those ‘big four’ apply?

A.A: Yeah, I think so. But again, I think it's very important to understand that there are different levels at which you think about those. 

Imagine that you're a single PM or a Head of Product who has no one else, right? You have limited mind space. And not only – it’s really limited time in a day or a week, right? 

If you only think about these four things, you won’t be able to think about essentials like:

• thinking about how the product should be built, 
• spending time with engineering, 
• building a trial time with customers 
• trying to understand how users indicate the best way to build
• sharing input with founders and the team on what they need to be able to execute

If you only think at these high-level you're not going to build the first versions that will provide traction to the company going into the next phase.

If you don’t think about them, then then you're going to make a lot of mistakes.

• your ability to ship faster will be bad, because of your execution, you didn't think about it, 
• your small team will not produce a lot because you thought about no productivity at all, 
• your ability to scale toward the next next level will be weak, because you didn't think about scalability, 
• the quality of your product is going to be crap, because you didn't care about that, right? 

So it should never be zero. 

When you grow and have people executing on a tactical and operational level, then a Product Leader needs to spend more time thinking about these four layers – because they're like averages, right? 

They're like things that multiply others. And then as a consequence, the product to be better and be a better solution for customers to choose you. So at the stage, where I am now, I am pretty sure every product leader that is in a 50-100-200 plus product, engineering, and design organization is going to be spending the majority of their time thinking about these four variables.

But you need to understand where you are in the spectrum.

7. Can the product team shift the direction of the product? If so, how?

A.A: Okay. So, again, the way I think about my framework is like: 'kill the extremes'. 

So the extreme side here is the team has 100% autonomy to shift everything. 

And the other side is the team has no authority and cannot shift it on its own. 

Both situations are bad. 

Because if you are empowered to shift at any point, it's anarchy, right? Suddenly, leadership and founders would think What the hell will happen? The product is going in a direction we didn't like. There's no consensus on this, etc. 

On the other side, if the team is completely disempowered to either bet in a different direction, experiment, etc, or contribute towards a pivot, then the team is going to be like literally a vegetable.

They're just waiting for others to say go in that direction. That's not good either. 

Here goes something I call a ‘Meet in the Middle’. 

The ‘Meet in the Middle’ is when the team is empowered with data and thinking space to have a critical view of: ‘where we are’; what's working, and what's not; what opportunities are proposed to the top leadership/management.

In this way together they can create and assess some sort of business casing on ‘why we should go there’, while at the same time being empowered to test their assumptions, (ideally, with tests that are small enough to not break the capacity of the team to deliver what is committed to in a certain timeline but still test to see if whatever they're proposing does make sense)

While at the same time ‘the top’ should work with the product team and discuss strategic opportunities and say:

• Look, guys, we see that there's space here 
• There's an opportunity here, 
• we see that this isn't working enough, etc. 
• Help us understand what is the solution space of guiding the ship that way 

This way the product team should be empowered to challenge it, discuss it, and propose a less or more invested way of getting there. Treating skepticism with testing is a good way to go.

8. How do you see the relationship between the leaders and the PMs, and what's important in that space?

A.A: Yeah, so I think, I think it ties into this 'Meet in the Middle'. Imagine having two reverse pyramids. 

So in my courses at One Month PM, we talk about what happens when decision-making is controlled in a very top-down manner. Leadership decides and tells the product team ‘this is what we're going to do’. This doesn't ignite responsibility to get the requirements done. 

The best situation is a meeting in the middle where the leadership works on the opportunities, like these are the strategic opportunities that we believe we should aim for. Understanding the business, understanding the customers, understanding the landscape, etc. will derive into data and information for the product team. 

Then the product team is responsible to design a solution space, understanding the opportunity space to design a solution space and the way they believe they can seize those opportunities.

Also, of course, challenge and propose opportunities they saw from customer interaction. 

And then they meet in the middle to discuss:

• timeline: when we believe we can do this, 
• resources: how much do I have to tackle it,
• scope: what is needed or not. 

In collaboration, this creates this triangle where you have to pick two, you cannot pick all three. 

If you give me limited resources in a specific timeline, then I have control over the scope. 

If you pick scope and timeline, then you need to give me the resources to achieve that.

If you pick the resources and scope, then I have control over the timeline.

So I think that ‘Meet in the Middle’ creates that little triangle there, that truly makes the difference in creating a good relationship between leadership and the product team. 

Want to learn even more about building products?

Thank you, Andre, for this insightful interview. Read below how can his experience and services help you build the product mindset needed to build successful products.

This article is a part of Linnify's Product Development Campaign built around the free 'Essential guide for rising entrepreneurs who want to future-proof their ideas and investments', written by Catalin Briciu, Co-CEO, and Andreea Ghic, Head of Product, who kindly invited Andre to this interview.

Build products that are needed - download now.

'The one thing that isn't solved yet is how to translate people's needs into a decision process that builds products.', he states.

Follow Andre and get his valuable content on LinkedIn 

Get Andre’s insights right into your inbox: Subscribe to his newsletter.

Get closer to product success: check the One Month PM programs.