Ben Barden

Product management and process tips

by

Review of 2022

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:

  • getting the flat decorated: this started in 2021 and was finished in March. Also got a new sofa and put up some artwork.
  • learning to drive: not finished yet, but I passed my theory test and will continue having lessons for a while yet.
  • releasing more music: though I took a bit of a break in the second half of the year, I’ve been working on some new tracks over Christmas. More soon!
  • changing roles/teams at work: I needed a change, and it’s going good so far. Also glad to still be in the company.
  • gaming: I got a PS5 in January and have played a lot of games this year. Maybe too many!
  • starting a product blog: aka quickproduct.tips – it’s early days but I’m hoping to keep up a rhythm of posting ideally weekly, if not every couple of weeks. Better than nothing, right?

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

by

How to practise good etiquette in team updates

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…

Timebox the session

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.

Nominate the first/next speaker

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.

Take discussions offline

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.

Try not to stay on after the session

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.

Avoid talking in-depth about process

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.

Refine and conquer

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.

by

How improving the Okta SMS flow would reduce support requests

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.

The Okta SMS authentication dialog.

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:

  1. You see a box that says “SMS Authentication” with some text: “To verify via SMS, click the button and you will receive a code. You will be able to enter the code on the next step.”. Then a button saying “Send code”.
  2. Upon clicking “Send code”, the code is sent, and you’re taken to the next stage. The text would say: “We’ve sent a code to your device. Please check the code and type it below. If it doesn’t arrive, click Resend code”. Then there would be a text field for the code, and a button saying “Verify code”. To avoid confusion with another button, perhaps the Resend code option could be triggered by clicking the text “Resend code”.
  3. If the code is entered correctly, voila – you’re in. If not, a message would say “Incorrect code” and give the option to request a new one.

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.

Potential improvement to the Okta SMS flow

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.

by

Flexible working in 2021

I see so many LinkedIn polls that ask: What split would you like between office work and working from home?

It’s still a new thing for many of us, hence it’s a hot topic. However, these polls have been done to death, and the answers vary based on what you do and your personal circumstances.

Instead of endlessly debating how many days to work from home, why not ask a different question:

How do we transition from mass working from home to true flexible working?

[Read more…] about Flexible working in 2021