How to Agree Ways of Working as a Product Team

Things feel a little stale. You’re stuck in a bit of a rut. The team’s energy isn’t quite what it used to be. And you’re not able to quite pinpoint exactly what has led you to feel this way. This can – and probably will – happen to all product teams at some point. The solution? A ways of working session might be just what you need to get you back up and running, feeling energised and rebooted.

Yes, it sounds a little cheesy, but walking out of a well run ways of working session can:

• help the team feel more engaged in their work and up for the challenges ahead
• provide a forum for the team to air concerns about the current process and identify problems / suggest solutions
• act as a contract for how you want to work together, leading to a greater sense of involvement from all concerned. Rather than the product manager dictating the process to the team, the team decide collectively how best to work (within reason!)

And it’s not just the times when you’re feeling a little less energised that a ways of working session might be appropriate. They’re also powerful tools to use when welcoming a group of new starters or when you’re tasked with working with a new team for the first time. The first 30 days of a new product manager’s time at a company should include this session.

Let’s explore how you might be able to run your own.

Step 1 – identify what’s up for debate and what’s not

Before the session with your team, have a chat with some of the key stakeholders in your business to identify which parts of the product development process can be changed without causing too much drama and which parts can’t.

I know, it sounds a little like asking your parents for approval before you go do something they disagree with but the last thing you want is for you to walk out of a super productive ways of working session with the team only for you to have to go back to them 3 days later to say ‘errr, we can’t actually do any of the things we suggested because of X, Y, Z reason.’

Some of the folks you might need to speak to beforehand could include your lead engineer / CTO, Heads of Product / CPO or other members of senior leadership. You should come away with a list of things which are up for debate with the product team and which things are not, along with reasons why. It might be, for example, that you can’t move away from using Jira since it’s an approved supplier, tied to a large commercial contract. Knowing this will help you to explain to the rest of the team why it’s not something that can be changed right now.

After you have agreement on the items up for debate in your ways of working session, document and share it with the wider team.

If, during your ways of working session, you discover that there’s unanimous outrage at something which was not on your ‘up for debate’ list, then you can always take that away as a consideration for further input with other stakeholders later.

Step 2 – hosting the session

If your team’s as opinionated as most product teams you’ll probably want to set aside at least a morning (possibly longer) for your ways of working session. Setting yourself a timer at the start of the session (let’s say for 2-3 hours), will create a sense of urgency to get to agreement within that time frame.

You’ll have already shared the items which are up for discussion so you can dive straight into the details, exploring each item one by one.

Let’s have a look again at the items we put in our example ways of working session earlier and tackle each of them separately.

1. Team name

You might want to come back to this one at the end since people will have all sorts of opinions on what the team name should be. Yes, you might balk at the suggestion that a team name is in any way important but in my experience at least, having a team name reinforces the idea that you’re a product team and not a collection of separate disciplines (product, UX, design, development etc).

Keep it fun and try to link it back to the company you’re working at. One fun way to generate team ideas is to put some rules or restrictions in place which link back to the company. So, for example, if you’re working in a company beginning with the letter P, your restriction could be animals beginning with the letter P.

2. Development process

This is a pretty fundamental question and it’s definitely one which needs discussion upfront with key stakeholders. More often than not your product development process is one which doesn’t make it to the list, at least not without prior discussion.

The critical question is usually: would you and the team prefer to follow a scrum style sprint process or would you prefer to adopt a more kanban style approach to software development?

This is where it helps to visualise the core differences between the two approaches so that everyone is clear on what’s actually being discussed. If you’re advocating for a particular process, come armed with reasons why you think one way or another should be adopted. If anyone reels off textbook scrum or textbook kanban under the guise of it being ‘proper scrum’ or ‘proper kanban’, it’s important to make everyone understand that different product teams will have different flavours of development processes, tailored to their needs.

Many factors will influence which process is best for your team but here’s some suggestions to consider:

3. Definition of done

Ready for release?
Released?
In review?
Code reviewed?
In QA but not back in progress?

To anyone outside of the product team, done means released and usable by users. There’s no reason why your definition of done should be any different, is there? Find out in your session.

4. Design process

Design processes differ largely from one organisation to another. Nonetheless, getting engineers and designers in the same room together to agree with you how you all intend to work together is a good idea.

Since this is a session about how the team should work together, aim to keep your design discussions focused around how design operates at a team level rather than going deep into the intricacies of design patterns etc.

Some considerations include:

• Input – at what point should developers get involved in the design process? Broadly speaking, the earlier the better, but if you’re still in the very early stages of design and plan to validate assumptions with users first, it might be premature to get engineers involved at stage 1.
• Components – if your tech stack makes use of components, it’s useful for designers to know which parts of your product use components so that this can be considered when creating new designs.
• Validation – which designs, if any should be validated with users through prototyping first?
• Reviews – should designers be involved in the review process before a new feature goes live. If yes, this can mean updating your development boards to explicitly include this step.

5. Stand up time, location, structure

‘Maybe we shouldn’t have a standup at all’

Some teams will want to get rid of the standup altogether. And this might work for some teams. But there’s something deeply helpful about setting aside 10 minutes at the start of each day to focus your attention, raise issues and prioritise problems. Without those precious 10 minutes you’re likely to need more meetings and one on one updates which will likely slow you down in the long run.

Use your ways of working session to agree how your standup should work, what the format should be and what time it should happen.

6. Retro time and cadence

I feel sorry for retros. They’re the one calendar invite that gets binned and reshuffled. Like a childhood friendship that you can’t be bothered maintaining so you cancel at the last minute. Just like that catch up over coffee with your friend you thought you could live without, however, once you’ve had your retro you’ll feel a lot better afterwards.

Less is more with retros. Every week is probably too much. Once a fortnight could be too much, too. Perhaps the best approach is to have one when you feel you need one. You and your team can decide what you think works best for you.

7. Team principles

Less tangible, but equally important, team principles are the foundations from which you and your team build your working relationship.

Invite the team to come up with their own principles and decide which ones work best for you.

8. Tools

Some tools will be mandatory for reasons ranging from security to corporate agreements, however there may be some tools which you’re not currently using that might help.

A fun way to agree on tools is to ask team members to dump on post it notes each of the tools they use personally or have used in previous companies. When you’re done, put the post it notes up and chat through which tools might be useful for your team.

How to actually agree on anything

OK, so we’ve glossed over something pretty fundamental throughout this so far, and that is – how exactly do you get 7 or 8 people with strong, different opinions to agree on anything?

Well, it’s a little tricky. But, it helps to put some structure to your decision making process.

Decide up front how you’re going to get to an agreement. Here’s a few ways which might work for you:

• Majority voting – everyone gets an equal vote. The majority wins. In a team comprised 60% of engineers you’re likely to get engineering-centric decisions. No standups, no meetings, no deadlines and a 24/7 work from home policy, for example 🙂 .
• Weighted majority – everyone gets an equal vote, but some votes are more equal than others. Orwellian inspired voting gives more weight to people’s opinions based on their role in the team (more senior / experienced folks might agree and influence less senior / experienced people to come round to their point of view).

In reality, it will be messy, but in most cases you’ll be able to get to an agreement after being locked in a room for a few hours together. Some things might need a follow up session or further discussion but try to discourage putting off decisions until a later date since the date rarely arrives.

Step 3 – share

Once you’re happy with your newly annointed team names, principles and ways of working, share them with the wider company. It might be that other teams are going through a similar process at the same time and if that’s the case, you can use the opportunity to compare and contrast how you’ve decided to work.

Pin your principles to the wall (and to your chat channels), so that you can remind yourself of them during the day to day grind.

Common problems and frequently asked questions

Nobody agrees on anything. What should I do?

Disagreements are natural, but if you’re genuinely struggling to get to an agreement on a particular point, focus on the things you can agree on. There will always be something people agree on. Focusing on the areas of agreement will diffuse the tension and allow you to move on. One workaround is to position your decisions as temporary; they are not final decisions to be imposed on the team forever, they are in flux and can be changed later if necessary. Using words like trial or experiment will help you get to agreement if you also agree to re-evaluate the decision in X months’ time.

My team are so negative it’s getting me down

Sure, humans can be negative. However, if there’s a negativity epidemic in your team, nip it in the bud by bringing people’s focus onto your team’s goals and achievements. Reinforce the achievements of the team and talk about how each and every member of the team played an individual role in that.

If one individual in particular has gripes, take some time to speak to that person individually to find out what’s up. Most people will appreciate just being listened to, even if you can’t solve all of their issues.

If two team members seemingly hate each other, consider helping them settle their differences in a mature way or, as a last resort, consider a team re-shuffle if their differences can’t be settled.

Our ways of working aren’t working

If you find that your ways of working are truly not working, use it as an opportunity to be explicit about what exactly isn’t working and use the retro or a future ways of working sessions.

Should all teams follow the same process?

Not necessarily, but major differences between processes should be monitored so that you can learn from what works in each set up and why. If you’re going to live with some of the potential inefficiencies of different processes for different teams, use it as an exercise to learn what works and what doesn’t and what that means for the wider team.

Who should be involved in the ways of working sessions?

All your product team members. Each company’s squad set up is different but it’ll typically comprise product managers, designers, engineers, QA, content writers. Key managerial stakeholders will need to be addressed beforehand and afterwards.

How often should we have a ways of working session?

You need to give yourself some time to let the ways of working settle in before you decide to change it again. Give yourself at least a few months using the principles and ways of working you’ve decided upon and reassess after that.