Scaling Right: Growing Impactful Product Teams after PMF

I want to share my mistakes and the challenges which I've gone through, and also I want to call out at the start that this is just as applicable to individual contributors - to designers or product people or engineers in teams - as it is to people who are managing.

The Initial Scenario

Imagine yourself in a company where you've found product-market fit. You've got one or two squads, and you need to start to grow. You need to start to put more capability into your product and what it is that you're building. That's really what it's about - anywhere from a couple of teams, how do we scale that up? How do we get ourselves able to grow our team so that we can then grow our product and help more people with whatever it is that we are trying to do?

Understanding Your Success

First question I want you to answer when you come to this is: Why is it working? Why have you found that product-market fit? You've found your users, you've found that bit of success - who is it that's making those important product calls? Could be:

• A senior designer
• A founder
• Any member of the team
• The whole team together (could be a very collective effort)
  It's really important that you need to understand why, or at least have a theory - why are you winning? Because the most important thing is that you don't break whatever that core thing is that's the reason for your winning. If that's a very product-thinking founder or a critical member of the design team or whatever that might be, the question is: Can you scale it?
  Could you add more teams, could you add more people without breaking that thing (whatever it is - usually a human or a group of humans)? If the answer is yes, then you've got your answer about how to scale - find ways to be more efficient with that team's time, find a way to get things out of their way.
  However, if the answer is no, then we can move on to the next step. But I think it's always important to step back and say: Do I actually need to change things? Do I actually need to do anything differently to how we were working before?

Three Initial Steps

1. Diagnose what is going to stop you - what isn't working, what are the challenges that you cannot scale?
2. Figure out how you're going to fix it - One of the biggest mistakes that I've made and I've seen and heard a lot of companies make is adding more people, scaling when you haven't got your core right. When you bring new people in, no matter how many people they are, they adapt to the team that there is there today. If that team isn't being successful today for whatever reason, chances are your new people are going to pick that up and start to operate in that way as well. You've got to have something working for you to scale.
3. Be realistic - If you are a small startup with a very product-led mindset and mentality across the senior team, you can go in a lot of different directions. If you are a small incubator within a large corporate, you're going to have a very different environment to scale and there's probably some things you won't be able to do.
   Be realistic about what you can do, be realistic about the change that you need to make and ask yourself the honest question: Can we make it? You'll be much more successful if you set your constraints and your boundaries based on what you think the organization will actually be able to do. Don't be afraid to go and ask some senior people or some longtime people who've been there: "Do you think we could get away with this? Do you think we could do this? How might we make this happen?" Because if you do that and you get a good signal/bad signal, that's a really good yardstick.

Diagnosis

Let's talk a little bit more about diagnosis. Here are some measurements which you can ask either yourself about how you're working, or about your team, or about the whole of your product organization. What they're really there to do is to understand which aspects are working and which aspects are not. You might want to tailor these sorts of questions to your specific situation, your specific organization, but use them as a way to have conversations with each other.
Use them as a way to understand:

• Why might this team be working?
• Why might this team not be?
• Why do I have this friction with my product manager?
• Why are engineering and design sort of feeling as though they're throwing things over the wall to each other and they're not really collaborating?
  Get into that state of honest diagnosis mode. You can do that:
• As an individual PM or designer or engineer within team
• As a head of across multiple teams
• As a C-Suite person working with the whole of the product organization

The Growth Framework

I promise there's not that many frameworks in my talk today, but I do want to highlight this one because I think it's really useful for this sort of stage. The very first section - that crisis of leadership, growth through creativity, and then growth through direction - tends to be that early startup stage. That's where:

• Your founder is very hands-on
• Whoever is making big product decisions is really hands-on and directing
• You might have a bit more of a delivery culture in some areas
• You might have just a much more collaborative culture because you can scale it
  You know that one or two or three people can work across a couple of squads and the CEO or founder can do the CEO job as well as that sort of product thinking, product direction job. But generally it breaks down here where you start to get past that scale and the direction starts to break down because there's not enough time available - humans can only scale so much.
  So you might have, let's say, a founder who's the real product thinker early on, who's very able to be that director at that early stage, but as you get bigger:
• They might have to go and do a fundraising round
• They might have to go and do the day job
• Their amount of time with the team will be much more limited
  And so you might just not have that context - the team just doesn't understand why this person is telling them to do this thing or whatever it might be. That's where things tend to break down.

Major Breaking Points

Let me talk through some of those biggest areas that I see breaking down, which I don't think tend to be in books or frameworks - this is just my lived experience of where you might find these problems.

1. Confidence Issues

You've got a team and they might be new to the business, they might be very old, but something is changing:

• They used to maybe be one of maybe two product teams, now they're one of five or six
• The amount of time they had with leadership has gone from hours a week to minutes a week
  You tend to get quotes like:
• "We can't commit"
• "We're not ready yet"
• "We haven't done enough Discovery"
• "We don't all agree"
• We're going for consensus
  My guidance: Figure out where on the scale you need to be between sort of full Marty Cagan and complete autonomy in this sort of ideal world, and micromanagement crazy boss from hell. There's a lot of space in between those two extremes. I think people tend to think of that as binary - as either "I'm going to tell you what to do" or "I'm going to leave you completely alone." I would really recommend you figure out where it is on that spectrum that the team needs to be.
  If the team isn't confident, you need to provide the environment or the confidence through demonstration to allow a team to make decisions and move forwards. How you do that will depend on the situation and who you are and where you're at.
  If you are a member of the team in this sort of zone and you feel yourself - you're just as a team, you're stuck, you just keep going around, you feel unable to make the decision - I'd really recommend you try and step up. Try to provide that confidence to yourself or try to shine a light on it and get somebody to help you do that.

2. Product Sense

Chris was talking this morning actually - I really liked his talk. He was talking about the famous Bezos quote of "Do we own the process or does the process own us?" I think that's spot on.
A lot of the time when I see something that doesn't look great, I'll dig into it with the team and I'll ask the team "What do you think? Do you believe in this?" and the first answer I get is "Well, we did a design sprint, we did all these things, we went through the process, we turned the handle on this process engine and this is the idea that popped out, and so this is what we're going to deliver."
And then you ask them again and you say "But what do you think? Is that a good solution? Do you really believe that that is going to work to solve that user problem?" And sometimes when you push on that, you get people step back and they're like "Not really... could be better, there's a problem here and I'm not sure about that."
I think there's a bit of a problem with a lot of the frameworks, lot of the approaches that are sort of like if you go through the process, good stuff comes out - and that's not true. You need teams with product sense, and you don't need every single person in about team to have super strong product sense, but as a whole you need the right blend of people. You need a couple of people in there who've really got this strong product sense.
This is my favorite quote on it from Mika at Figma, which she basically defined product sense as:

• User empathy
• Plus creativity
• Plus experience
  The good thing is most of this develops over time - it's not a case of you're born with it, you develop it. It's a skill that you can work on. If you or the team or whoever it is isn't really coming up with those solutions, you're just not feeling it, I'd recommend thinking about which of these areas, which of these three things might be lacking. The experience one basically just comes with time, but you can hire that in. Everything else I think you can develop.
  If you want to know more about this one, Lenny's podcast with Mika is very very good on this topic. I would recommend it - in fact, if you're not subscribed to Lenny's podcast I recommend you do that anyway.

3. Velocity

I mentioned this in the confidence section - you need confidence for velocity, but you also need a mindset for velocity. I think there are good examples of just this can't-do attitude which sometimes creeps in, and it can be infectious. You need to think about how you deal with this at every step:

• "We can't do it because we're blocked from another team"
• "I've got all this other stuff in my calendar which is taking up this time"
  What you need to do is think about where you or other people are on this spectrum - are you a full-on pirate or are you the worker bee, the drone in the cube farm in the office?
  You probably don't want either end of that spectrum:
• The pirate is just going to break things, probably not going to do things in the right way ethically, they're going to burn bridges behind them
• The worker bee is just going to be heads down, ship the code, ship the code, not really caring about that stuff, perhaps overly bureaucratic, overly political
  You want to be somewhere in the middle, and where in the middle depends on what that team is working on:
• If it's a growth team who are all about experimentation and moving fast and moving those metrics, you want a bit more of the pirate
• If it's a platform team, you want a bit more on the worker bee end of the spectrum
  But everybody needs a bit of pirate in them and everybody needs a little bit of that worker bee in them.
  My second favorite quote of the day from Paul Allen, the CPO at Intercom: "Fast gets good faster than good gets fast." Basically, speed is a quality all by itself. If you can move fast, build momentum, get things done, you're going to learn, and as you learn you're going to get better. It's much much easier to move fast and figure out what is working, what isn't, than to try to be perfect.

Speed vs. Velocity

Speed without direction is nothing - speed by itself can be spinning wheels, it can be just going in any direction. You really need velocity. So you want a team that:

• Has the ability to move fast
• Has the confidence
• Has the right team makeup
• Knows where they're going
  Ask yourself:
• Is the strategy understood?
• Is everyone bought in in the team and around the team in whatever it is that they need?
• Are you comfortable with the ambiguity in whatever space that you're in?
  That lack of comfort in ambiguity can really slow you down - it's that tyranny of choice when you have:
• No strategy
• No clear KPI that you're trying to move
• No real understanding about why your users are doing what they're doing
• No clear view of core underlying needs
• No clear view of the problems you're trying to solve for them
  Pretty much anything could be the right answer, and so you've got this infinite choice problem.
  If you're in a team and you feel any of these things are triggering, don't be afraid to ask for direction. Don't be afraid to ask for these things because your job in the team is to be successful, is to have that impact, is to solve those user problems. If you need outside help to solve them then great - that's not a problem. The primary thing you're there to do is to solve those problems.
  If you're outside the team and you see some of this happening, I'd recommend that you're not afraid to give a little bit of direction and see if that helps:
• Get a little bit more involved
• Ask some questions
• See if you can help by being a bit more hands-on or a bit more practical
  It doesn't mean micromanagement, doesn't mean telling them the answer, but it might mean unsticking them from a particular spot or situation.

Putting It All Together

I think you've got to hire the right people - it's absolutely critical. You've got to understand:

• Whether you want the pirates or not for that particular role
• Do you need somebody with super high product sense, or is the team already indexing really well on that?
• Can you get somebody perhaps who has a bit less experience but is really keen and a bit of a high potential?
  Really understand who you need in that team on a team-by-team basis. Think about each of the members of the team:
• Is it complementary?
• Is it all set up?
  Sometimes you might need to move people between teams just to find that right blend of people because personality clashes happen and that's okay - nobody's necessarily messed up there, but it's something that you've got to deal with.
  I would always bias mindset over hard experience - somebody with the right mindset who's got that right blend of "let's try it" pirate with really understanding the platform requirements or whether you're about to create an absolute world of pain in tech debt.
  All of that comes down to active management. Active management if you're in the team is about asking yourselves:
• Are we succeeding?
• Asking those difficult questions of yourself and of your co-workers
• How are we doing?
• How do we really think we are doing?
• What are we missing?
• What are we lacking to be successful?
  Asking that question is half the problem, and if you get there, you're in a good spot.
  If you're managing these teams, then it's really about:
• Giving the teams feedback
• Letting them know where they stand
• How do you feel they're performing?
  It might be a difficult conversation, but it's a very important conversation for you to have with a team: "Yes, lots of hard work, we love what you're doing, but we're not making progress. Let's talk about why we're not making progress."
  Often when you break the ice on a topic like that, you find there's a good conversation behind it where the team actually feels relieved and is like "Ah yeah, you're right, we weren't feeling good, we do have these problems, let's see how we can work together to fix it."
  Sometimes it's not just about working on the product itself - it's about working on the product team to allow you to solve those problems.

Conclusion

Basically, it all comes down to the right people, and there's no right or wrong answer for what the right people are. It's about:

• Your company
• The team
• The problem you're trying to solve
• The experience that you need
• Who is currently in the team
• Are people motivated?
• Do they feel able to be creative?
  Creativity involves a bunch of failure - have you got the right ability for people to fail to allow them to really flex those creative muscles? Are you solving those impactful user problems? Do people understand what that is? Have you got support for them? Is the strategy clear? Is the user understanding clear?
  If you bring all that together, I think you can deal with your confidence problems. I think you can deal with challenges in terms of scaling, for instance being able to step away from a founder leading a set of questions or whatever it might be.
  If you tick those three boxes, I think you're in a good spot. And it's not about a framework, it's not about some magic formula of autonomous teams or using the SAFe framework or whatever it might be - it's about the right people in the right place doing the right things.

Q&A Session

Q: Speed can cost quality - how to mitigate that?
A: That's a really good question and it's a completely subjective answer. There's no perfect balance here, there's no perfect formula. First of all, I think you've got to ask that question - you've actually got to be able to say well, what is the quality that we're trading off here and you need to be able to make a call about is that an acceptable level.
I think the best way of doing that is probably to have a minimum quality bar - to really understand where that quality bar is and for the senior team to be able to help an individual team hold to that bar, to say "Well, okay slow down" or "You know what, that's an acceptable thing." And that's part of that decision-making and confidence which I think you can bring to a team.
If you don't have an idea about the minimum quality standards at the moment, I think that's worth investing in in your team. Where do you want that bar to be? Feature parity across platforms, for instance, is one of those common ones. Where are you willing to accept what's your QA approach? All these sorts of things all contribute into quality, but I'd recommend having that set of principles about quality almost before you get into each individual trade-off. It'll save you a lot of time.
Q: Why do you think mindset will beat experience?
A: Because I think with the right mindset you can solve pretty much any problem which is thrown at you - you being either you individually or collectively as the team. Because whatever level you need to get to, you can at least go down to first principles and then build back up from it in the way that you are then wanting to do.
Experience is a shortcut for that. So experience is great if you've got it, but experience with the wrong mindset won't work. Some of those quotes that I had there, particularly the ones around velocity of "Oh well, we're blocked by this team" or "The ticket wasn't clear and so we're going to bump it to the next sprint" or whatever that is - that's mindset. That's either a can-do or can't-do mindset, and those might be super senior people or super experienced people who are saying those things.
And that's going to massively slow you down. In the right company, in the right situation, the right structure, that will be fine; in others it won't be. So what's the mindset that you want for your team? And I would always say that that is non-negotiable - you need that mindset to be understood across the board.
Q: The problem with speed is the "good enough" mindset. Instead of improving the "good enough" product, a lot of organizations just move on to the next "good enough" product.
A: It's 100% right. I think companies that do that or teams that do that, it tends to be this sort of feature mindset of "Right, we've built this thing, right what's the next thing?" It's like tick boxes on a SaaS feature comparison sort of thing.
If you're building a SaaS product and you haven't found product-market fit and you're in a particular situation where sales have committed to a bunch of stuff, yeah, maybe that's the right thing to do. But "good enough" isn't about shipping features - it's about have you really deeply solved that user problem and are you seeing that flow through in however you're measuring it?
That could be anything from something like NPS or CSAT all the way through to something big like LTV or CAC or whatever it might be. And so I think as a team you can really control that by focusing on what's that user problem and how you're measuring it. And if you haven't made that difference yet, don't move on.
Yes, you've shipped a thing, but it's only just good enough and so we haven't had that impact - we're not seeing whatever it might be, it's not meeting our quality bar, it's not whatever it is. So again, it comes back to that mindset, it comes back to those sorts of things.
But I very much recognize that pattern - it's a nasty place to be, but I think that's really about influencing up and trying to get that sort of set of agreements, set of principles in the team of this is what we mean by "done." "Done" isn't shipped the thing - "done" is we've solved the problem and we understand what's happening there.
Q: This people-first mindset - how do you learn to hire exactly the right people in the right place?
A: It's tricky. Hiring is hard, hiring is really hard. It's taken me a long time to get even passable at it. Some people are absolute naturals, so one thing I would say is if you've got people who are just really good at hiring:

• Lean on that
• Really get them involved
• Get them hiring as many people as possible
• Get them to be teaching others and training others how to do it
  Another good way is to sit in on good interviews, in inverted commas I would say. But I think stepping back from that, which might be the thing behind the question, is what is "right" is essentially what it's about. And that generally isn't "Oh we need another front-end engineer" or "We need another PM" or whatever it is, and so "Right, where's our PM job spec, dust that off."
  It's about thinking about what "right" means. Yes, you might have a PM with a set of experience, number of years, number of whatever, but:
• Where do you want them on that pirate-worker bee spectrum?
• Answer questions like that to allow you to filter for that
• Think about your hiring process - does it allow you to get into that?
• Do you have your best people doing the hiring? Because your best people are probably the best at sniffing out other great people.