Product management and process tips
I’m experimenting with Substack for my content.
On Mondays, I’ll be writing about tools, ways of working, blogging tips, recent articles I found interesting, plus some highlights from my blog archives.
Thursdays will be focused on product management and Agile tips. These will replace my separate product blog. Running two blogs is a lot of extra work, so why not merge my efforts?
You can follow my Substack content here: https://benbarden.substack.com/
Hope to see you there!
2022 felt like things getting back to normal: food, walks, trips to the office, though still plenty of working from home (a good thing).
Highlights, not all pictured:
Next year I have some aspirations (I dare not call them resolutions) but I’ll post most when things happen. Setting resolutions and posting them online can be motivational, but I find it stressful. I’ve got a few things planned though.
Reposted from instagram
Many of the teams I’ve worked with have some kind of regular team update – often a daily session.
In the team update, each person in the team talks about how things are going, and they can raise any questions or issues.
These can be really useful but it’s important to steer them a bit. Here are a few tips for how to do that.
How to implement these tips
A team should agree to try a new approach and see if it helps.
Changes should be trialled one or two at a time. If you make a lot of changes in one go, it’s easier for the team to push back purely because it’s more disruptive.
With smaller increments, you can try things out, get used to them, and keep them if they feel like a good change. Then you move to the next change.
Onto the tips…
The team update shouldn’t be an exhaustive rundown of everything. Long drawn out updates can lead to people switching off. Keeping it high-level will help everyone digest the updates.
15 minutes is a pretty good timebox to use – if you’re using Scrum then this is already how long the Daily Scrum should be.
Nobody wants to prematurely end the session at exactly 15 minutes if someone is speaking. Someone can call out when the time reaches 5, 10, and 15 minutes if it’s useful.
Plus, the change can be gradual – if a team is routinely taking 40 minutes to do their update, getting this to 20 or 30 minutes is a good start.
Giving updates in the same order gets repetitive, and can make people at the end feel that their updates aren’t valued. Varying the order can help with this.
Don’t ask “who wants to go first?” – as this can also lead to the same order every time. The first person to speak could be the first or last to join the update, or they could be nominated.
When a person has given their update, they nominate the next person.
Make sure everyone in the team has a chance to speak – don’t miss anyone out.
It’s ok to ask someone a question about their update, but don’t let this take over the whole session.
If it needs a wider discussion, this should be taken offline – i.e. discussed outside of the team update – but it’s important to make sure this happens.
The person asking the question or the person giving the update could arrange a discussion with the relevant people if needed.
Whether it’s in-person or virtual, it can be tempting to “stay on” to have the offline discussions there and then.
That can work if there’s only one discussion – but will get messy if there are more.
The risk is that the discussions will feel like they are part of the shorter team update, and may end up being discussed as they come up instead of afterwards.
Plus, people may have other things to do, or they may need a quick break.
Your approach may vary, but my view is it’s best to give people the opportunity to leave the current meeting before getting into further discussions.
It can be tempting to talk about the team update in the update. After all, you’re doing it there and then, and any thoughts are fresh in your mind.
It’s ok to hear the comments if you have time, and give a quick answer if possible. Anything more and it’s often better to set up a dedicated time so the topic can have sufficient space for consideration.
The team may come up with small tweaks to the team update (and other parts of your process) as they get used to it.
Refining the team update as people think of improvements helps to remove pain points and keep things fresh.
Keep doing this as much as you need to.
When reviewing product feedback, it’s sensible to delve into the “why” of each request.
What problem does this solve? Who does it benefit? Why is it important?
But when product behaviour leads to support requests, I try to think about how to reduce those requests.
When we rolled out Okta last year, we got a lot of people saying they chose the SMS verification method, but the code never arrived.
After a bit of testing, the issue became clear: the user needed to click the “Send code” button or the SMS message wouldn’t arrive.
It sounds obvious – but if you look at the dialog, it’s not all that clear.
You need to click “Send code” to get the code. But this is an odd UI pattern, because the “Send code” button looks like a Submit button for the “Enter code” field. Whereas in fact, the “Verify” button is the Submit button.
We’ve had lots of support requests for this. We end up saying “you need to click the Send code button” and the person feels silly. But I understand why people don’t realise they need to click the button. The layout doesn’t make any sense, as it doesn’t work in the sequence you’d expect.
I think it would be better if it did this:
And because it’s easier to show you than describe it well, here’s a bad picture of the proposed layout I drew in about 2 minutes.
Perhaps Okta Verify is the better method to use. But still, while SMS is an option, I think the two stage approach would be much simpler to follow – and I’d argue it would reduce support requests.
By making software intuitive and easy to use, we save time for end users, and save time for support teams. Win win.