This video interview (below) is a section of a longer fireside with Patrick Collins, CPO of public company Zip (ASX:Z1P). There is 25 people in Product and 150 people in Engineering, so we dig into the way Zip is structuring given their explosive growth revolutionising how we think about payments.
Zip organizes teams in triads of: Product Manager, Engineering Lead and Designer. They then have 12 “durable teams” that worked on fixed part of the product. So there is no rotation of teams according to a project, they are wedded to the part of the product they “own”.
No BA's or Project Managers
The video starts with a discussion around the triad and what happens when PMs ask for extra team members such as Product Marketers, Business Analysts or Project Managers.
Patrick’s contention is: “I just haven’t seen any problems that the triad can’t solve.”
He has a spicy response to requests for these extra roles: “I just think you’re doing your job”.
Because hiring PMs is challenging given the high demand and lack of experience outside Silicon Valley – Patrick is bullish that these roles CAN become great PMs, but old habits/tools like Gantt charts have no value in the product-driven Zip culture.
Scaling is splitting
Patrick sees that durable teams – led by triads – is a scaleable structure that works from startup from public company.
He reminded us that startups typically begin with: a hacker, a hustler and a designer. In other words the triad is often the basis of great startups because all the essential jobs can be done with these founders.
The great challenge for startups is to control the propensity to split your focus by adding “New Features”: Patrick says: “if there’s not a strong overlap with the customers that you’re meeting on a daily basis and the problems that they face” then
I was under the illusion that a public company – with all their investor expectations and oversight would need to have a predictable and accountable course of execution. I was wrong!
“Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do.”
Instead, the company works from a very startup based ethos that 90 day OKRs map well from company strategy to sprint level execution and feature delivery.
For the uninitiated, OKRs stand for Objectives and Key Results, you can read more here, here and here.
“when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions.”
So the insight here is that Product Teams can always busy, but they need to have their efforts directed in harmony with the companies goals. The other insight that supports the “No Roadmap” principle is:
- a Product Team can run an experiment
- if that experiment is underperforming in achieving an OKR, then it can be abandoned.
- another experiment can then be run with the intention meeting the OKR.
This makes huge sense as a sanity check on any sprint scheduling process. Its not important to be busy – its important to get jobs done related to OKRs.
The diagram above (sorry, no social distancing!) shows the ZIP approach to quarterly planning for the 12 durable Product Teams. Using the aforementioned OKRs, Product Teams present to a “Product Council” features from their backlog. The goal is to “lock-in” the sprints and features for 90 days that map directly to OKRs, Product Strategy and ultimately Company Strategy.
Its an intelligent structure with feedback loops from Strategy to steering (Product Council) to prioritisation (Product Triad) to execution (Product teams of engineers, designers, QA etc).
Below is the 10min snippet that delves into these topics – Patrick is crystal clear with nuggets that all teams can benefit from hearing.
(sorry about some of the sync problems – WFH is really pushing neighbourhood network limits at times!)
David Jones 25:09
this probably speaks to a challenge too which is that a lot of people who might have been businessanalysts or project managers now see that the Holy Grail could be a Product role because product is now, you know, what, a decade ago, a product manager with somebody figured out the wording on the back of the Cornflakes packet. “Here’s where you call for consumer care”. Now, the product role is really a central part of the success with a customer and a real pivotal thing. So, a lot of people are running into that, but it sounds like what you’re saying is they’re bringing some baggage from their previous roles. Whereas really, they need to strip back and actually say, “What does the product really look like?” Is that what your are saying?
Patrick Collins 25:53
yeah, I’ve definitely noticed that with some of my team members at Zip, I think when I explained what a great product team looks like. I am fortunate, and the reason I joined Zip is that is already is a pretty strong product culture and it’s been set up pretty well. And I don’t feel like I’m trying to change something from a from a different kind of culture. But I definitely do notice, like, for instance, I’ve noticed that some PMS, talk to me often about why they need a BA on the team, or why they need an analyst dedicated or why they need a Product Marketer dedicated to them. And I resist, and we do end up in some pretty heated debates on it. But, I guess simplistically, I would say, I talked about that “product triad concept” of of an engineering lead, and a product manager and a designer. And I just haven’t seen any problems with that triad can’t solve. And so the idea that you would need to get dedicated folks from different roles to do that. To me I tend to use fairly harsh words like “I just think you’re doing your job”
Patrick Collins 27:06
Between those three people if you can’t figure that out, if you need an analyst to kind of understand the requirements of your platform I don’t know what you’re doing as a PM and tech-lead so and so yeah, I’ve had some I’ve had to kind of I think challenge some of that thinking for sure. That doesn’t mean that a strong BA can’t transition into a good PM role or a good project manager can’t transition into into being strong PM as well. Is there some baggage there?…..Potentially because I think in a modern product concept, product team approach that the shuffling of duties around between the team lead and the product manager is a little unconventional to the way you might see a traditional project team work.
David Jones 28:01
I think you said 25 people in product, 150 or so in engineering? So that’s one:seven-ish, I guess. Is that right? And anyway? Yeah. And then durable teams. So given that the product team has probably got a bunch of sort of like a management layer in there, does that mean you’ve got like 15 durable teams operating at the same time?
Patrick Collins 28:28
Yeah, it’s about right now about 12 durable teams. And in my product team is designers and UX. So there was some double up in the counting there. I think maybe give or take 15 dedicated Pac Managers. We’re all different of all different seniority levels and all different capabilities and skill sets as well. All product managers are not created equal.
David Jones 28:52
Well, as Monty Python used to say, That’s “bloody luxury”. You know, how do you how do you translate that back to like a smaller, smaller startup that’s perhaps got some product market fit. And this still sort of being dragged in many different directions. How would you give in your Fifth Finger experience? How would you think about durability and stuff like that; “tribes” or whatever. When you really when you really are wearing 40 different hats, you know,
Patrick Collins 29:22
I think it scales perfectly well, I think the idea of having…..when you think about a startup, normally you’ve got a hacker, a hustler and a designer, right? So, that’s not unconventional way to start a startup and sometimes the designer will be a freelancer or sometimes it’s (the founders are) a hacker and they’ve kind of got to go recruit someone to do this, the sales side. I think that is a very common organizing unit for a smaller business and it does scale really well. They just kind of keep splitting the problem down and scaling that up into a bigger company.
David Jones 30:02
It’s the surface area. So what happens is a start up, you’re supposed to have a smaller surface area, you’re kind of working on that nugget that really matters. And then you start to bolt on different things. So again, it comes back to focus. It’s like, if you’re gonna build this other project it’s gonna divide and conquer you. Right? Yeah. Okay. It’s always dangerous to work – So from a product perspective, particularly as a small team, considering new features, or considering new product lines is like one of the most dangerous things you can do.
Patrick Collins 30:38
It’s a challenge for sure. If it’s not if there’s not a strong overlap with either the customers that you’re meeting on a daily basis and the problems that they face. It’s a real danger to introduce a new problem into an existing team.
David Jones 30:52
Yeah. Okay, good. All right. So you’ve got you’ve got your teams. We had a chat on Sunday. And I said, What are your roadmaps look like? And you had a response…..
Patrick Collins 31:06
I said, “we don’t have roadmaps”, and you were shocked. Right?
David Jones 31:11
I was delighted. Go, yeah. Give us give us the good oil here.
Patrick Collins 31:22
I guess it goes back to that startup, like, if you were if you were four people in a room in a startup, and you were running really hot of a problem, would you build a roadmap for what you were doing? Wouldn’t right? You’d want to know really clearly what objectives you’re trying to resolve, what objectives you’re trying to accomplish and what problem you’re trying to solve. You’d be laser focused on trying to solve them. And you’d organize around that and the only time you might make a roadmap as if a VC asks you “what’s the plan ahead” and so you might go cobble one together on an ad hoc basis and do it. And so I see a scaled product organization no different. Why? Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do. So, it’s an anathema to the idea that a product – so I guess my organizing principles, we just went through, we do quarterly product planning cycle, all 12 of those product teams presented yesterday to a group that I’ve organized called our Product Council and we predominantly focused around their objectives and key results (OKRs). So we had a lot of time debating what what this team should be trying to solve. I’m really proud to have gotten to that point over the course of a couple quarters because when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions. And so, by focusing on OKRs (Objectives and Key Results), we’ve kind of forced the team to really understand what they want to get done by the end of June. And we forced the executives in the Product Council to align around that as well. And there was listed set of initiatives that they’d gone and done sizing to understand how they might deliver that there was a lot of research that had gone into it from a customer perspective as well about why that was good problem to solve. And each of those teams know that if they go to deliver a feature and they’re working on that feature, and as they test it with customers, they might only be halfway through design and development and testing the customers and realize it’s just not going to get them there. It’s not going to get them to their OKR. Then they have free autonomy to abandon that feature and move to the next most promising feature. And so it’s through that lens of crafting and curating a backlog of things that they’re going to work on and testing all the time to try to hit these objectives. That means that a roadmap feels fairly pointless. That doesn’t mean that I don’t have people in the company asking for it. And there have been some people asked for a roadmap and there certainly are features that our partners and customers need deadlines for to be able to integrate to. There are times where deadlines are critically important. But yeah, OKRs and backlogs is our primary organizing mechanism rather than roadmap.
Patrick Collins 35:22
And it is guided by a company strategy as well. So both the company strategy, there’s a product strategy. So there is other high level objectives and inputs that we’re considering. That helps guide the initiatives and the objectives that they’re trying to accomplish. I mentioned earlier that our mission is to become an everyday payments provider. That is an overarching “north-star” for us that does provide a pretty strong filter for the things that we consider to be valuable and important.