How to get your product team firing on all cylinders
I’ve joined teams of different shapes and sizes everywhere along the maturity scale - including regularly standing up new teams - across many industries, working on different products and problems, each with its own unique set of constraints.
Working in different guises, be it business analyst, delivery lead, product owner, or product manager, there’s been one ever-present running through the lot of them. You could call it a few different things: best practice, flow, execution, tightness, maturity, continuous delivery. It’s something I’ve tried to nurture in every established team I’ve been welcomed into, and something I’ve championed in each new one that I’ve had a hand in forging.
And it’s crucial.
Perhaps even more so than a lot of the producty goodness that takes place upstream and that has a habit of hogging the limelight amongst thought leadership.
Because when all is said and done, your vision, your OKRs, and your continuous discovery will all be for nothing if you can’t deliver working, scalable products.
Setting the bar
My ultimate goal is to develop a shared understanding of what good looks like. This will differ for every single team, but the core components are typically:
If joining an established team, my default stance is to let one or two cycles go by before suggesting improvements (so a couple of sprints, or a couple of meaty features going through the board), to a) give enough time to take stock and spot patterns, and b) to ensure sufficient time has passed for you to get to know the team, and for them to get to know you.
There are some exceptions here - where there are “no brainer” opportunities that would be really low risk that may warrant an earlier intervention. An example might be an obvious bottleneck in a flow that doesn’t get addressed within a few days. Being proactive and showing by doing can be a useful tactic in your first few weeks with a new team.
Working towards one or more artefacts that convey this succinctly can prove very useful - not to wave in a teammates face as if it were GDPR legislation, but as a guide for anyone new joining the team, and as a reminder when you’re unsure of what to do with that rogue Jira ticket, or how often your data playbacks are, or what the URL is for the team’s Datadog dashboard.
Team APIs can prove helpful here, but my go-to is a team Miro canvas that incorporates or hands off to a Team API. Learn more in our product team canvas article, which hands off to our free Miro template.
Team principles
A session to talk through what the team expects of one another, regardless of specialism, and the things that really matter to each person.
Five minutes of collaboratively shotgunning thoughts onto a wall or a Miro board, followed by some affinity sorting and then dot voting is usually enough to reach a consensus. There is often crossover with the other core components (ways of working, tooling etc.), and this is fine. Repetition adds emphasis.
A few usual suspects I’ve seen bubble up from principles sessions:
- Quality
- Professionalism
- Slack etiquette
- Awareness of unavailability
- Flexible working
- Focus on value / outcomes
- Delivering iteratively
You can go in with an example to talk around, but this can skew the session and can put some people on the back foot.
Roles and responsibilities
A similar format works well for this session. Throw all of the team roles up on the board, then sprinkle on all of the things each person expects from each role. Some affinity sorting should enable you to map out expectations and begin plotting out who takes responsibility for each.
One thing to be wary of here: I’ve noticed an anti-pattern whereby teams are too dependent on one person for something. I strongly advocate championing the notion of, whilst one person may lead the charge on any given item (the tech lead may be ultimately responsible for the technical direction of the team, for example), ultimately the whole team have a level of reponsibility here - or at very least the other engineers do.
Ways of working
This is probably the meatiest of the four core components and needs breaking down to do it justice.
Flow
The most impactful teams I’ve worked in have all had a simple and slick kanban board on which they visualised their work in progress. They had a clear definition of ready and definition of done. They understood what constituted moving an item of work from one column to another. Crucially though, whilst they all knew what “best practice” looked like, they were pragmatic enough to know that these were not hard and fast rules.
Establishing excellence in this department doesn’t happen overnight, and I’ve found that less experienced teams tend to benefit from more structure as opposed to less.
A dedicated session with the whole team to review (or define) the shape of the board is a good start, as is heading into retrospectives armed with challenges to any obvious bloat or bottleneck.
Here’s my go-to kanban board if you require inspiration:
In-depth estimation and measuring team velocity are two things I do not advocate, regardless of the level of maturity of the team. On the odd occasion, I’ve seen story pointing trigger some conversations regarding hidden complexity or misalignment, but I’ve never seen either of these techniques deliver anywhere near enough value to warrant the effort. And a lot of the time they sap the energy and morale of a team whilst painting the illusion of under-achievement given things inevitably take longer than anyone predicted they would.
Cadence and ceremonies
My personal preference is not to work in rigid sprints, but I do find the associated ceremonies useful.
At the very least, a regular session to review goals for the next week or two with the whole team, a regular retro every two or four weeks, and a daily stand-up are a given.
Other regular sessions that I’ve found useful include:
- Monthly session to review team goals and stuff on the horizon
- Weekly or fortnightly user research playback
- Weekly or fortnightly data analysis playback
- Weekly or fortnightly shaping session, covering defects and tech debt as well as the next couple of big-ticket items that are looking to move the needle
Working in the open
All of the above items can help here, but If there isn’t a culture of transparency already instilled - or worse still, the opposite - this can sometimes prove difficult to foster.
Leading by example has served me well here, over-sharing and over-communicating in general - particularly in the early stages of a new engagement.
There is a lot to be said for encouraging an active Slack channel, pairing and mobbing (not just the engineers), “just jumping on a call”, championing three amigos sessions, and creating artefacts as part of conversations which can then be shared with any and all.
Tooling
A lot of this is a given for an established team, but it’s still a useful exercise to review and document the applications that you use, who the owners of each are, and what you typically use them for. You’ll almost always unearth tools that you didn’t know existed.
For a new team, this is an essential baselining activity and will help you understand the constraints that you’re working under, as well as the preferences of your colleagues.
In summary
Building successful, scalable products is not easy and requires a focus and rigour that is often lacking.
The best way to instil this, and to ensure that you always strive to deliver at your maximum, is to accept that you - along with every other member of your team - are ultimately accountable for this.
Anyone can raise the bar, so don’t feel like you need to wait for somebody more experienced to join your team. Grab the opportunity by the scruff of the neck.
