When telcos first emerged the business model is simple. Something akin to the water company, or the electric companies business model. Most utilities charge you for some kind of usage and thats it.

Competition in the market of utility companies is usually rare.

Telcos have to compete on brand and image, their company values and of course cost.

When these type of companies, who usually have huge amounts of capital, decide they want to enter other markets by making digital products, I think they find it hard to innovate or come up with original ideas.

They often come up with copycat product ideas. Because they have always been a utility-type company, which solves one need, I think they find it hard to discover customer problems to then solve through digital products.

Telcos are always large coperations. I haven’t heard of any telcos which are startups. And being a corporation sized company comes with a lot of political and bureaucratic baggage.

Because they are so big, it means they move very slowly. Launching a new product offering to market can use a lot of resources and take a lot of time compared to a more nimble startup.

And even if they try and do an “agile transformation” or some such they often fail.

Telcos don’t make your own digital products.

All of these frameworks and methodologies equip product managers to make highly scalable and successful products. But it depends on the people we work with if those product’s success can be realised.

Learning all the jargon, the frameworks and the various techniques is the easy and fun part, it takes about 2-3 years. But then you’re faced with the reality that building great products requires working with and aligning a very large number of people. And you realize all the tools in your toolbox don’t equip you for workplace interpersonal problems. You realize you’re unprepared for company political games and power moves.

None of the books, or the seminars, or the YouTube videos train you how to work with stakeholders who pull you in different directions. They don’t teach you how to handle people who are very hard to work with.

I think it takes about 24 months to either build a successful product or your job goes to shit and the people within your organisation are too hard to work with.

I want to study and learn everything about the people side of product management. I want to write in-depth reports and analysis about it. Building great products can’t be done alone. As a product manager you can’t do anything without your team and all the stakeholders. You’re dependent on them for the product’s success.

Learning how to work with people is crucial to a product manager’s success.

Join my newsletter to hear more from me on this: https://adamwintle.com/

They are good communicators. They have excellent written and verbal communication skills, so that they can effectively explain complex ideas to a wide audience. They know how to listen and understand others’ points of view. They also know how to persuade and influence others. They are flexible and open-minded, willing to try new things and adjust if they aren’t working. They have the ability to make hard decisions even if people don’t like them.

I’m not sure. I suppose it’s because we’re always in charge of things and things never go the way we want them to. If you’re a product manager, then you know what I mean.

As a product manager, you need to be a leader and be able to handle lots of stress. But there are ways to make it less stressful. One way is to have good mentors who have been through the same things you’ve been through.

A roadmap is a high-level plan that shows how you intend to achieve your goals. It typically covers a longer time frame than a project roadmap (which is more tactical in nature) but doesn’t go into as much detail.

It’s essentially a highlight reel that provides context for the project roadmaps, and it can be used to communicate your plans both inside and outside of your company.

A good product roadmap should contain the following:

1. What is the purpose of your roadmap?
2. What does success look like and how will you know when you get there?
3. How will you know if you’re headed in the right direction?
4. What are the main risks that could prevent you from achieving your goals?

I try to share my opinion last in meetings and discussions, and let others go first. I’ll probably be the one to make the final decision anyway. So what’s the point in me speaking first? I get no input from the rest or the team that way.

And more often than not my original opinion changes during the meeting because I’ve heard the team’s thoughts on the subject.

My approach is to try and facilitate a meeting; and guide it, rather than just “run meetings”.

I try to be very interested in all ideas; no idea is a bad idea.

I find this helps make everyone feel involved in the decision making process; and they’re not just there to do whatever the product manager tells them to do.

I also encourage everyone to share their thoughts in meetings, sometimes the quiet ones have great ideas too but they’re too shy to speak out about it.

I’ve also found developers to be some of the best problem solves. It makes sense when you think about it, engineers are solving complex technical problems all day long. So just because they’re not a “designer” doesn’t mean that they’re going to have bad ideas.

I always write an agenda first, and encourage other people to add their discussion items to the agenda before the meeting starts.

I have a rule, if there’s no agenda then we cancel the meeting. And I discourage people from adding ad-hoc discussion items once the meeting has started.

A side note; I used to do this thing where I’d keep the agenda to myself, as if it were some sort of secret or it would be a big surprise when the agenda was revealed.

My assumption was that it would be bad if people discussed the meeting agenda before I’m there. I might miss something important or someone might make a decision without me! This used to actually give me a lot of anxiety.

Now I circulate the agenda as soon as I can which also includes all the problems we’ll be discussing in the meeting. This gets people thinking and in the right frame of mind before the meetings even started.

More experienced team members come prepared with their own ideas ready to show to the team; which would have been impossible if I’d kept the agenda secret.

And because I’m the product manager nothing goes onto the roadmap unless I agree to it, so any “decisions” made before the meeting happens would have to be run by me anyway.

On Micromanaging People

A few years ago I was always micromanaging the team I worked with. Looking back at this is painful and makes me cringe!

This is the antithesis of creating high performing teams. Micromanagement = uncreative and low performing teams.

Micromanagement drains a manager’s energy and gives you extra cognitive overhead which you don’t really want anyway.

Micromanagement is:

1. “Hey just checking in on the thing you’re working on”
2. “How’s it going on the task, any progress updates?”
3. Informing people “you’re half way through the sprint, so the task should be half completed by now”
4. Adding unnecessary pressure in other ways, such as “we have a deadline for this”
5. Asking to access the in-progress working files, just so I can look if I have a spare moment (Figma is really bad for this because it’s completely open and collaborative. I try and only open Figma when the teams ready for me to add comments and feedback)

Doing any of the above tells the team you don’t trust them to do a good job. You don’t trust them to do what they’re experts at. And it also just drains your own energy because you’re constantly involving yourself in everyone else’s work.

I find the trick to a high-performing team is this:

1. Outline the objectives required that the team achieve, and explain why. I usually go through what outcome would be best for the product, the business and the users. During this step I try to stay entirely in the “problem space”, no solutions proposed yet. I consider it my job to have fully formed and well-prepared problem statements written as well as a product vision statement and other related artefacts that the team may need.
2. Next step is to start listening to people’s ideas for a solution. I encourage a debate and for everyone to contribute to the discussion.
3. Once we have a general consensus on a direction to head I ask the team members who’ll be working on it how much time they need before they want to give me a progress update. Let’s say for example it’s 5 days.
4. We’d schedule another meeting in 5 days and I won’t speak to them about it unless they need my help. I won’t hover around their desk to “just check-in”.
5. The team working on solving this problem have to self-organise in any way they like. They organise their own meetings (with or without me there) and they can go sit next to each other even if they’re designers and developers.
6. Then we meet again in 5 days and discuss the proposed solution (maybe in the form of some wireframes, a click-through prototype, or just a presentation deck; whatever the team comes up with). I try to facilitate the meeting to a final decision and path forward. If we can’t make a final decision then we schedule another meeting in a day or so.

I find this works 80% of the time. The team is fully empowered to create a solution, which they are now responsible for delivering. They have to figure out how to work together and self-organise. Tougher for more junior team members, but it’s not that hard to get used to it.

What happens if the team comes back with nothing?

I share my feelings of disappointment and ask where things may have gone wrong; then I try and troubleshoot with the team and make a plan to move forward.

I usually remind them:

1. I can always help them, they just need to ask
2. If we need more user data we can arrange a usability study, or we can gather data in other ways
3. We can hire a consultant or someone who’s done this before if they need a boost of expertise
4. And in 1-on-1 type settings I ask about it and see if I can get anymore insights

For the 20% when this approach doesn’t work then I try and dig a little deeper:

1. Maybe there’s a skill gap in the team, so some training or an online course could be needed
2. Maybe they’re just used to being told what to do, so they need to be nudged out of their comfort zone and attempt to problem solve without “management’s” help
3. And sometimes there’s an attitude problem. I’ve worked with people when you self-empower them they abuse the autonomy and slack off and consider it an easy ride. Usually with these types of people I give them two chances and then we’d have to have a conversation about them leaving the team. But that’s rare.
4. Sometimes there’s also some team members who do more or the work compared to others (the 80/20 rule), this is common and it just takes time and practice to spot who does the majority of the work. You can then help guide and coach the less productive team members.

And with all that in mind I still think I have a lot of room for improvement, and I’m probably not remembering some obvious things.

A few other thoughts on interpersonal skills

When I was more of a junior product manager I used to rush into meetings stressed out and frantic. My meetings were breathless.

I used to hardly smile in meetings and I used to cut people off mid-sentence because I presumed I knew what they were going to say anyway.

Smiling, nodding and looking people in the eye when they speak to you go a long way in showing people you really do care about their opinions.

All of these past behaviours made me in general unpleasant to work with. And gave me the reputation of someone with low interpersonal skills in the team. My 360 feedback from my team back then was embarrassing!

I was just known as the stressed product manager who didn’t have time to hear what people wanted to say.

Now I try to create a sense of calm when I’m around team members. Even if I’m completely stressed inside my mind, I don’t find any benefits to putting that stress on everyone else.

So I have been binge reading on GPT-3. Basically from my understanding it has every single text ever written, all of the internet, and a lot of private datasets and archives as its training data.

Then OpenAI (Founded by Elon Musk) have honed in one a single Machine Learning approach called “Natural Language Processing” (NLP). This isn’t the most popular Machine Learning approaches. But OpenAI decided to keep pushing forward with it and see how far they can get.

So with everything every written ever as training data and the NLP approach the system started to be able to predict the most probable and common next word that that input would most likely have.

So by priming it with a few paragraphs of text it’s able to then predict the most probable answer.

Which happens to be a completely average and generic, answer, which also happens to be something sort of like a horoscope; generally they all feel like they could apply to anyone.

Or another way to look at it, it’s the most probable answer for any give question or input.

GPT stands for Generative Pretrained Transformer, which I have read basically means it uses a gradient. It puts 175 billion (for GPT-3, and 8 million on GPT-2) parameters on a scale which looks like a gradient, and then it ranks every single parameter on that scale. Then from the scale it can predict what is the most likely next word in the sentence based off of the primer.

GPT-4 is going to be mind-blowing.

I primed GPT-3 with a paragraph from John Cutler’s blog post https://medium.com/@johnpcutler/15-things-you-should-know-about-product-managers-f488513d246 and asked it to shares it’s thoughts on the topic:

My question to GPT-3:

What are your thoughts on this?

Many junior PMs (or folks transitioning to PM) are thrown into the deep end. They are “assigned” to a team, handed the old backlog, tasked with “coming up with a new roadmap”, and set loose. Until you do, people don’t trust you. But when you do, they doubt that too! Because everyone is so busy, and because PMs are expected to be resourceful, you will not see the level of support and care for onboarding that you might see from an engineering org. I’ve talked to leaders who think “sink-or-swim” is a valid way of “separating the wheat from the chaff”. The challenges here are immense. Imagine that the junior PM is paired with a group of experienced makers; they’ll get eaten alive. Or…if everyone on the team is junior; they’ll get no help from the team and will flounder. Either way, you have a problem.

GPT-3′s Answer: 

What can we do to solve this? But not only that, you’re correct, I will not be able to address all of your concerns as they come up immediately. And one year is too long to wait on something that can help a product manager in the moment.

So if I’m understanding you correctly, you want a formal mentorship program on top of the new role you’ve created?

This doesn’t sound cheap or easy. Do you have any ideas on how we might get this going?

I’ve been thinking about this for years, and I’m still not sure how hard it would be. It would have to be a joint effort between product and other folks who can train and mentor.

So either we all do it together, or product does it alone. I guess I just don’t understand why this is so important. Why do you care if a junior product manager is successful or not? What difference does it make to you?

But it isn’t quite as easy for someone who has no experience with mentoring or program management.

You want me to mentor you? Really? Yes, I believe you can help me understand what I should do next, and believe that together we can make a list of steps to take to make the team more successful. After all, I don’t want to leave here unless the team succeeds!

Here are some tips:

1. Understand the needs of each stakeholder and try to build a relationship with them.
2. Find out what is most important to each stakeholder. What do they care about? What drives their behavior?
3. Build a strong relationship with them by communicating often and transparently. This builds trust and will help you tremendously in the future.

These are the people who have a high-level overview of your product, but aren’t actually doing the work to create it.

1. Have regular meetings. These don’t have to be long meetings, but it’s important to communicate with your management stakeholders on a regular basis.
2. Be realistic. Try to avoid over promising and under delivering. It will only hurt you in the long run.
3. Don’t oversell. Be honest about what you can and can’t deliver and when you can and can’t deliver it by.
4. Be prepared. If you’re going into a meeting without a solid idea of what you’re going to say, then you’re probably not going to come out of that meeting looking so good.

And then there’s Customer Stakeholders: These are the people who will actually be using your product. It’s important to find out as much as you can about your customer stakeholders so that you know what they need and want.