In March 2021, we started working with an exciting new client to develop a mobile app to serve their digital community of people in their fifties, sixties and beyond. This month, we’re so proud to see the Rest Less app launch, allowing members to browse a personalised feed of hundreds of articles and resources covering health, money, lifestyle, careers and much more. I can genuinely say it’s been a pleasure to work with Rest Less, and it’s a project the 383 team have really enjoyed.

As we prepared for launch, I had the chance to chat with Sara Stephens, CTO and Co-founder at Rest Less, about their journey through Series A funding, the challenges of scaling teams in a fast-paced environment, and how prioritisation more often than not comes down to good communication.

‍

‍

Watch the whole conversation here, or read the transcript and some highlights below.

Watch now

‍

‍

Transcription

Leon
Hi, and welcome to this episode of Byte Sessions. I’m Leon and I’m Product Director at 383, and today I’m joined by Sara Stephens who is CTO and Co-founder at Rest Less.

Rest Less is a digital community for people in their fifties, sixties and beyond, offering content, guidance and resources on everything from work and careers to health and relationships. Today we’re going to be talking about how to prioritise at pace, which I think is a really key topic, especially for a fast-growing startup like Rest Less.

As we know, any product team has to have strategies for how they decide what to do next, and there are all sorts of prioritisation frameworks and techniques available to help us make decisions. The trick is figuring out when to use those things, and how to make them work within your organisation, as no two organisations are the same.

This is really relevant in a fast paced scale-up environment such as Rest Less, where you are trying to create a brand, you’re developing new features, you’re growing your audience, you’re growing your team, and you’re raising funds, all at the same time.

It’s a balancing act that Sara is well versed in, and she’s here today to share some insights on how Rest Less are managing priorities and some of the lessons they’ve learned along the way.

I’ll hand over to Sara for a quick introduction to her background and the Rest Less story so far.

Sara
Hello Leon, nice to see you again!

We’re well versed in this at Rest Less, yes, but definitely not perfect!

Rest Less has been on a three year journey. It initially was the brainchild of Stuart Lewis, our CEO and my Co-founder. He and I were both looking to start something with a social impact mission, but also with a business model behind it.

When I met him, Rest Less was still a pitch deck, and he sold me on the idea of how much impact and change we could have across this macro economic trend that people are younger for longer, and society needs to wake up to that. We took it from there, just Stuart and I, and got our first round of investment, grew our team to five, and then spent about a year at five of us, and grew our membership base significantly, which unlocked our ‘pre-series A’ funding, you could call it. That kept us going for a little while.

COVID hit, and we had to accelerate our plans significantly and, without sounding too cliche, pivot a little bit from our initial plan and continue to grow our membership base.

We’re at 600,000 members now, we’ve just closed our series A funding, and we’re now at about 40 people. So, it’s been a bit of a crazy, crazy journey! And I just love the impact that we’re having on the over fifties demographic and the culture that we’re building at Rest Less.

‍

‍

Leon
Awesome. Yeah, the growth is crazy. I think when we started working together in March, it was about 400,000 you’d just passed? It keeps just going up and up and up!

Sara
Yeah, exactly. It just shows to us that there’s a real need for what we’re doing. This demographic is so underserved and so neglected – it definitely wants what Rest Less has to offer.

Leon
Where there’s such an underserved audience, there’s obviously a lot of potential for new services and features. Talk me through where you start when it comes to identifying what’s really going to add the most value to your community, and then back to Rest Less as a company as well.

Sara
This is really hard, right?! Especially because, often, the product mantra will be, go deep and really focus on one thing… and we’ve gone really broad and a little bit against that. So prioritisation is really, really tough.

There’s loads of frameworks out there that we could use, such as MoSCoW and RICE and various different things. I think for us, internally, ultimately it comes down to impact. How does it affect the drivers that you’re running at as a business? And then, how much does it cost you? What’s the effort to deliver on that impact?

‍

‍

Internally, we’ll look at things on a qualitative and quantitative basis; looking at numbers and analytics and stats and things like that, but also that qualitative side, actually talking to your audience. What do they see as a particular problem for them or something that they would find really impactful? There’s loads of tools that you can use to do things like that, but ultimately you can just pick up the phone or have a video call. All of that feeds into how you start to prioritise things.

The other thing I like to do, and get the team to do, is question incoming requests. If you don’t have laser priorities, lots of different departments within your business – you’ve got sales, you’ve got customer service, you’ve got the CEO, you’ve got marketing – they all think, ‘I’ve got this great idea that we should definitely do!’. Which is amazing because you’ve got really excited and invested stakeholders, but then you have to figure out, actually, how does that slot in around everything else?

By asking questions, you’re getting them to think about those high-level drivers, such as engagement or growth, and how their idea feeds into those, or multiple of those. When they start to think about that, they start to ask, okay, is this actually going to have the impact that I think it is? Or is it just because I think it’s a pretty neat feature and I’d like to see it…?

Leon
It’s thinking about the outcome that we’re trying to drive and not just the feature, and does that feature really help us get to that?

Sometimes, maybe there’s a feature that you need to put in there because you’ve need to satisfy a stakeholder, or an investor, some other reason outside our all-perfect idea of prioritisation. You’ve got to just do this thing because it’s actually going to progress us in another way.

That can be quite hard, can’t it? To bang that drum around, ‘always think of the outcome, does this add value?’. Sometimes, we’ve just got to do this one thing.

Sara
You’re totally right. That balance is super hard. Sometimes you do push things, even if they’re low impact. You’re almost… not keeping people happy, but giving a signal of progress and pushing them along. It’s part of your stakeholder buy-in. You’re almost trading off, because they’ll give you a bit of room later on.

Even with the perfect prioritisation model, you still have to go against it a little bit of the time. There’s things that aren’t just business impacting that allow you to unlock and move forward.

‍

‍

Leon
That’s the key thing with product, really, isn’t it? Especially for 383, as an external party. A lot of the time, we’re there to be the guardians of the product and to demonstrate that if we do this thing, this is what the impact could be, but ultimately to serve the needs of the business and the audience. You have to play the game and think, well, in order to progress this further on, we’re going to unlock ourselves here by doing this.

Sometimes perfectionism can get in the way. You can be too puristic with prioritising things and not understanding that, actually, it’s people, all the way through this – either internally, stakeholders, end users – and we have to be able to please multiple people multiple times.

Sara
A hundred per cent. It’s all about people, right? Making sure that flow and that machine is working. Whatever it really takes to push it forward.

‍

‍

Leon
We’ve all heard of the excited CEO – I’m sure Stu wouldn’t mind me saying that! I guess, if they can’t be excited then, then who is going to be, right? In your experience, how do you keep those stakeholders engaged and excited in that gap between, ‘I’ve had an idea, and ‘It’s been a week and I’ve not seen it’…?

Sara
Stuart is amazing and he is a super excited CEO! I love that about him because I have been in roles where you don’t have an excited stakeholder, and then it’s really hard for you to get motivated and behind what you’re doing. So I would a hundred percent take an excited CEO any day!

Having said that, if they’re coming to you on a daily basis it can be a bit disruptive. One of the things that we try and do is, first of all, figure out how that person likes to be communicated with. Are they a visual person? Do they like to see an email update every now and again? Or do they like to have a conversation with you? If you unlock their communication style, they start to get a bit more comfortable, and getting across your thinking and progress will be so much easier.

Once you figure out how best to communicate with them, getting them involved at the right stage is really important, constantly changing and adapting when you get them involved. In the beginning, you might want them really involved as you’re trying to figure things out and demystify what it is you’re working on. Then, as that trust and that confidence starts to build with your stakeholder, maybe they pull back a bit.

I find demos can work quite well, with the caveat that you shouldn’t deep dive into areas that aren’t fleshed out yet. I’ve seen instances where stakeholder get caught up on, oh, the copy isn’t right on that. You need to steer them to, yeah, we can change the copy, that’s coming later, but what we’re really focusing on now is the flow – any feedback on that?

I also find that getting excited with them works – yes, we really want to do this, this is awesome, let’s go! They will feed off that as well and buy into your excitement and feel that you’re going to push things forward. It’s really, I think, at its core, communication. Lots of communication.

‍

"Sometimes perfectionism can get in the way. You can be too puristic with prioritising things and not understanding that, actually, it's people, all the way through this - either internally, stakeholders, end users - and we have to be able to please multiple people multiple times."

Sara Stephens, CTO & Co-Founder, Rest Less

‍

Leon
Absolutely. You don’t want to dampen the spirits when you go through all the different steps that are needed to deliver something. You want to keep them excited in the areas that are important to them, whilst also communicating, for example, yes, we’ve got an idea and we might have a visual that represents it, but we’ve now got to try and connect all the backend sources to that, and we’ve got to think about the unhappy path, when things go wrong…

If you don’t communicate properly those problems become apparent towards the end. It can then look like you’ve slowed down when, actually, the fact is that things weren’t necessarily considered at the start because you hadn’t gone through the process.

Getting stakeholders involved in just a little bit of that, for them to see it, makes them more aware that what appears to be just a simple button, actually, that button has different states, and that data has to come from somewhere, and when it’s clicked it has to do something else. Then they can appreciate what’s involved.

It doesn’t necessarily mean they stop with the ideas…!

Sara
Exactly! You’re spot on. It’s expectation management and I think making that really, really clear is super important. And also delivering that in a really easy way to understand. If you start going too technical, you’re going to get switch off – I’m not interested, just go make it happen…

Leon
I was just going to say the same thing. There is that balance between trying to give enough detail so that people understand how complex it is, but not giving them the minutiae where they think, I don’t know what you’re talking about, and now I’m a little bit embarrassed, but I can’t admit that, so I’m just going to switch off from it.

‍

‍

Sara
You can see the glaze… Uh-oh, okay, I have to reign this back in. Let’s come back out again!

Leon
Absolutely! What would you say the pitfalls and challenges are that you’ve seen both at Rest Less and in previous places when it comes to prioritising features and functionality?

Things like technical debt – we want to get something out there, so we do it, and then we’ll think about it later. As companies grow, that becomes a much bigger problem because you’ve got more people to keep happy, right?

Sara
The tech debt conversation is always a tough one for startups. You’re constantly making compromises in order to meet delivery timelines and constantly fighting fires, so it’s an uncomfortable spot to be in, finding that balance. You have to make sure know what you’re sacrificing, and you do make the effort to at least chip away at it within your development culture, take it bite by bite.

There are certain things which are major architectural decisions. Sometimes you just have to revisit them and go back. We talk about type one and type two decisions, right? If you make a type one, that’s pretty fixed, that’s going to impact you quite significantly. Type two, it’s okay, we can change this later. It’s trying to get the type one decisions as close to perfect as possible, whilst still accepting, if you’re growing really fast, it’s probably going to be wrong in a year’s time. You have to really sit comfortably in that.

If you have a good relationship with the business and you’re constantly saying, we’re making this decision, it’s going to affect us later, just so you know. We’re going to have to come back and do it. With that clear and open communication channel, your stakeholders should be aware of what’s coming at some point in the future. I find their mindset is always, well, if we get there, that’s going to be a great space to be in, so let’s go.

Leon
You can try and plan for every eventuality, but you don’t know what the future’s going to hold. Take COVID. No one knew what was going to happen. We all thought, we’ll go and work from home for three weeks, we’ll be back in the office… 18 months later… who knows what’s going on, right?! Trying to forward plan can sometimes slow you down.

Does the perfect solution really exist? Probably not. As long as, like you say, you have a process where you’ve considered the options, you’ve documented your decision, and you know, at some point, you’re going to have to pay this off, that’s probably the way of getting round it. If not, you can end up spending so much time trying to build this ‘perfect’ system that, A, you delay delivering some other value, or B, you don’t end up using half what was built.

How have you managed the team, especially your developers, to feel like they’ve got confidence to move forward, knowing that they might have these issues lurking around?

Sara
I totally empathise with the development team when they know that they’re making a sacrifice and it will be them that’s having to come in and clean it up later. I’ve been there. I know what that’s like!

You start to get the team on board by going back to those drivers and those outcomes that we want to get to. As a collective team – not a tech team, as a business. The tech team are very much a partner with the business, not just serving them, right? Once we get behind those drivers, the benefits that we all get collectively out of making a compromise are worth it. Once you change that mindset, moving from, oh, this isn’t technically perfect and I’m carrying this, towards, okay, I’m making this compromise, but it’s for the good of the business.

‍

"It’s trying to get the type one decisions as close to perfect as possible, whilst still accepting, if you're growing really fast, it's probably going to be wrong in a year's time. You have to really sit comfortably in that."

Sara Stephens, CTO & Co-Founder, Rest Less

‍

Leon
It’s quite a hard mindset shift, isn’t it, to get through?

We’re not asking you to cut a corner, necessarily. What we’re saying is, think of the bigger picture, and by getting to this point faster, we’re getting to this next level. It’s always a balance – as long as there’s time to come back and to perfect it, and it’s not always just hacking things on. That’s where you get into that conversation with the business and say, if we keep doing this, at some point, this will stop us from being able to move forward… what do we do?

We had something similar with a client where it started off as a really quick marketing website, almost an MVP, thrown together. Then things get added to it, added to it, and of course, seven years later, you’ve got this monolithic thing where you daren’t touch something because it might blow up. It’s just about working and it looks okay from the outside, but it’s an absolute nightmare to manage it. You have to admit that, actually, we need to rebuild it.

We’ve just gone through, last year, a rebuild of a new platform, and actually we found that there’s all these lessons we learned around how not to do it which fed into the new product. We were able to build it more quickly, we’ve been able to maintain it, and actually deliver value a lot more quickly.

For anybody that’s in that space where they feel like they’re just hacking things on, make sure that you’ve reviewed that with the business and you understand that you’re not trying to do this so it’s perfect for the devs; you’re trying to do this so that everybody can collectively move forward. As a result of that, it then gets better for the devs.

It does require more… empathy, I guess, from everybody to understand what that’s like, doesn’t it?

Sara
Yeah, and for the business to understand that the development team are carrying this tech debt and they are going to want to work on it at some point. It’s not always easy to see the business impact of that, or to communicate the business impact of working on tech debt.

That’s part of what my role is – to highlight that if we refactor this piece or pull out this specific component and make it a lot cleaner, the stability is going to go up, which means more engagement with our audience, tying it back to a business goal and a business outcome. That’s when you can start to attack it.

Leon
That’s when it works best. If the message is, we need to spend three months replatforming this thing, and in a CEO’s eyes we’re just going to be at the same place we are now, well that doesn’t make sense. They would rather add more features or value in there.

It’s about pointing out that what we’ve got at the minute can’t be maintained and we can’t grow unless we do some of those things. You’re absolutely right, it’s about understanding what language works well for them and what’s important for those people, almost removing the technical side and saying it allows us to get to these goals.

Sara
What’s also really important there is the sequencing. It’s so hard to find the right time to do that stuff.

Certainly for us, we can’t do major pieces at the moment because we’re still in that stage where we just need to get a little bit more traction, and then we can start to look at it. You were talking about a seven year old project, and that I can understand. It’s probably doing quite well and they can justify starting to reinvest. At the moment, for us, it’s all about growth and those goals.

‍

‍

Leon
Yeah, absolutely.

So, we can have these prioritisation frameworks in place, we can get stakeholder buy-in, we can talk about when things happen and try and plan things out. The reality is, we’ve still got to have people around to do it.

As a small, growing team how does that change your prioritisation? You’re hiring quickly, you’ve got to get the right people in, and they need to be onboarded. It’s almost like you’re changing the wheels as the car’s moving. Talk us through those challenges and how you’ve overcome those.

Sara
One of the key things for us is getting really comfortable with not saying, ‘this is not my job’. Everyone gets stuck into everything. Obviously there are boundaries to that – I’m not going to expect the dev team to pick up the phone and have a sales call, although they did do that right at the beginning.

It’s getting comfortable with being uncomfortable and just picking those tasks up, asking what you need to do in order to push this forward. That whole ‘this isn’t my remit’ thing just isn’t for us, certainly at our stage. As you get bigger, you start to have room for more specialised roles and expertise and your team can deep dive. But at the beginning you’ve got much more generalised roles.

We just, as you know, hired Hugo (Ostyn, Product Manager) and he didn’t join us until six weeks ago. We’ve been running about two years without a product function, and 383 have massively helped us to bootstrap some of that.

What was happening is the dev team were actually having to pick up some of that product function and flex that muscle into requirements gathering, what’s the outcome, getting into that product engineer mindset. That’s been massively beneficial, because the impact is far greater when your technical team understand what it is they’re trying to deliver.

Leon
We were having a similar conversation the other day about when 383 were smaller. You have to do everything, right? You’re the project manager, you’re answering the phone, you’re sending the invoice… We didn’t have a cleaner, so we were washing up and cleaning the kitchen. You’re literally doing everything!

I liken it to, if you’re walking towards the bin and there’s rubbish on the floor, you pick up the rubbish on the way to the bin. You don’t think, oh, we need a cleaner because it’s messy in here. If you see it, you just do it!

When it comes to that hiring process, that attitude is really key, isn’t it? You want everybody to be able to drive forward.

Sara
When you’re scaling a team and when you’re struggling to prioritise, one of my first questions is always, do we have the finances to bring in somebody else? Can they help and support us? Can we bring in the expertise that we don’t have?

That’s what we did with 383 on the product side – come and help us and be our product function and bootstrap the team whilst we need to get through this stretch period and give that elasticity to our capacity.

Leon
You want to be doing things quickly and there’s that balance between getting specialist people in or more generalists and training them up. How have you played that so far with the roles that you’ve hired, especially in development?

Sara
We’ve been fairly generalist, I would say. Some specific knowledge, but fairly generalist, and people that are happy to get stuck in.

Where we’ve identified we need expertise, usually it’s to do with speed as well. So, we need to deliver that three month project. It’s going to take somebody a month to get up to speed. And also there’s probably some things they won’t get quite right, because they’re learning, right? That’s natural. That’s often when we make a decision to work with a partner, a product agency or consultant, a staff augmentation type of thing, to bootstrap our team and get that expertise to pull it over the line.

And that partner works with us, just to be clear, as a really connected team. In my view, saying, go and work on this product, I’m not going to have any involvement, just doesn’t work at all. It’s not good for the business. It’s not good for your current team. It’s got to be that integrated partnership.

Leon
Let’s stay on that thread there. So, you’re looking at bringing in external people, whether that be contractors, freelancers, an agency. How do you make sure that that knowledge doesn’t just get lost when those people go?

Sara
That’s massively important, and it’s also scary for a business. We’ve had conversations internally where we’ve asked, how do we make sure that the knowledge, like you say, doesn’t just leave with an agency and we don’t retain it internally?

That’s why I like that integrated model, where your suppliers act essentially as part of your team. You’re having stand-ups together, all your ceremonies together. That knowledge transfer, the communication – again, communication! – is there and you’re constantly exchanging knowledge. Also, you’re putting down everything on paper, on your Wiki or whatever you have within your business and retaining your JIRA, or Trello, your repositories, all on your side.

‍

‍

What’s really hard is to form that relationship with an agency that just joined you and you’re suddenly putting two teams together. There could easily be a ‘them and us’ scenario. How do you foster a good relationship, build that bond, almost overnight? I think humans naturally like more time to build trust and reliability with people.

What I’ve found works is treating the agency as part of your team – that they’re yours as well, having regular catch-ups, capturing that iterative feedback. I know that we do that quite a lot with 383. And having open channels and open communication on those things that could be improved, or could have gone better.

Leon
The whole landscape that we’re working in is so uncertain – we know what we want to achieve, but by the nature of being agile, we haven’t yet figured out how possible or feasible that thing is. There’s going to be hurdles along the way.

I think sometimes you can get into that trap of thinking, and we’ve been there in the past, we’ve got to deliver something, because that’s what we said we’re going to do. But actually, we couldn’t have known we were going to do that at the start. So, if something does go wrong, we can’t hide behind that. We’ve got to put it forward as soon as we have that transparency and then say, how do we navigate it? Do we invest more time in it? Do we change the direction slightly on what we are going to do?

It does come back down to prioritisation, almost regardless of whether that’s internal or external or not. It’s having that communication and saying, actually, we were on this path, we thought we were going to do these things… We’ve done these three, there’s a curve ball at number four. We didn’t expect that – what do we do? Do we carry on? How do we unblock it? And how does that change the prioritisation?

It’s about really being agile. You’ve got those goals and those drivers that you mentioned, so can we do something else that gets us towards them? Which means we don’t have to do everything we’ve said, but without it feeling like a cop-out.

I think it gets highlighted from our perspective, because we’re conscious of the fact that we’re external, we do come at a premium, and therefore we have to add value. But the value is also in fixing some of those things. Maybe not everything, not all the work, is code and features. It’s the thinking time as well.

Sara
Yeah. Definitely. Those curve balls happen, as we know, and you do have to work together. I think almost the worst thing you can do is approach it with an attitude of, you said you do this, why aren’t you doing this? You’re wasting time having an argument, when really you should be coming together to fix the issue and try to move forward. How do we make this happen?

Of course, it is a complicated relationship. I’m not trying to oversimplify it. You want to make sure that you are, as a client, keeping some level of pressure on, but I think you don’t want to take that too far, and you don’t want to get into the habit of knocking heads.

‍

"Not all the work, is code and features. It's the thinking time as well."

Leon Barrett, Product Director, 383

‍

Leon
I think there’s something really interesting that you said at the start, that the tech team shouldn’t be seen as a servant to the business. It is part of the business. A lot of the time we see the product functions as an extension of IT, and IT are traditionally the people that you go to when something’s gone wrong with your printer or your mouse, can you fix it for me?

I guess product has grown from this. There’s that expectation of, we’ve said we want this thing, go and make it happen. It’s very one way. Then we start seeing challenges. For example, we can’t prioritise because we’ve got all these stakeholders asking for things and there’s not an appreciation of what those things mean, or how long they take. That’s where you get those questions around, well, how do you prioritise? What’s your formula?

Actually, part of what we’ve spoken about today is that there’s not a framework that’s going to solve it. It’s about communication and people management and stakeholder management all the way through.

Sara
If you tried to model it, you’d be there forever, with all the different variables and things that can happen.

Sometimes you have to be a bit feel-y with it, which is really not comfortable for some people. It’s really hard to get that across, actually.

Leon
There’s loads of tools that we’ve used – things like Product Board and ProdPad -in the past where you can plot things out and you can write the benefits. But again, it’s almost like ideas are one thing, and the execution is everything else. You’ve then got to actually go and deliver it. Then, even when you start delivering it, it’s not perfect because things still change.

This is quite a contentious topic that comes up quite a lot in conversations about product. When you’re planning things, obviously prioritisation is as much about saying ‘no’ and ‘why’ as it is about saying ‘yes’. How far in advance do you tend to plan in terms of what you’re going to commit to and start doing?

‍

‍

Sara
Not very far! It’s a contentious topic for sure.

We try and, at least, have themes in our head – Q3, we’re looking at this theme, and Q4, we’re looking at this theme. I’d like to call out that point where you say it’s about as much saying ‘yes’. I think that’s super important, switching to, ‘yes, how can I make it happen’, rather than, ‘no, I’ve got too much to do’. But then also saying, how does that balance with what we’re trying to do? “Yes; how does it work with everything else?”

How we’re approaching it at the moment, because obviously we have a board and they want to see what Q3, Q4, next year, look like, is to have those high level themes and a rough idea of the things that are going to go into those three months, with the understanding that it might flex.

We move really fast. We’re constantly getting data and feedback in, and so the plan might change. If we make a change, it’s for the better of the business. It’s not just because we made a change.

‍

We’ll typically flesh out around two weeks worth of tasks and tickets. During those two weeks, we will constantly get feedback and adapt. Like you say, the curve ball comes in, that’s going to knock something out into the next two weeks. How does that impact the rest of the line?

You can’t get too caught up with planning, certainly at the stage that we’re at. There’s other projects where maybe you’re dealing with compliance, or huge corporate things where you have to plan it much, much further in advance. Maybe that’s slightly different. But certainly where we’re at, you can’t plan too far.

I did it at the beginning, I tried to plan too far out. I had all these great tickets with lots of acceptance criteria, and then they sat in the backlog and didn’t do anything. That was a couple of hours wasted!

Leon
There’s a tweet that I saw the other day. They said, imagine that you had a box of 12 donuts given to you today and you could only eat one donut per month. So, the new one today tastes fresh. Month two, probably tastes okay. Month three, starting to be horrible… By month ten, you’re not going to want to eat it. It’s almost like that with the road map, right? If you’re trying to plan everything out from today for the next 12 months, it’s not going to happen.

That’s one of the things we see when people are trying to adopt an agile mindset but they’re still delivering it in waterfall. It’s really hard to prioritise when you don’t know what’s going to come up in the future. You’ve committed to doing this thing in six months’ time, but something more important has come in… it’s impossible, right? There’s no framework in the world that’s going to allow you to do both those things. You can either say, well, we’re not doing that thing in six months’ time, or you try and do two things badly and it doesn’t really work out.

The tip, like you say, is to have themes. We want to increase engagement, so everything we’re going to do for this period is going to increase engagement. Judge us on whether we’ve done that when you speak to us, not whether we’ve got the answers right now. Because if we knew it, we’d do it all next week and we’d sit back for 11 months, right?

Sara
When it comes to deadlines and the sticks in the sand, so to speak, sometimes you have to have those. We have that for certain thing that we’re running at and can’t move. So then you have to switch and say, well, what is it we can take out of the sprint? Or what is it we can slightly flex?

It might not even be take out, it just might be a reduced version of the feature set. For example, you might have to redesign something in order to deliver it, but actually, is there a way you can reuse a different component in order to test that feature lightweight, which is good enough for the stick in the sand deadline? Or, is there a way that you can scale the team for a few months? That’s how we deliver against both of those sticks, trying to be a bit more creative with how you reach those milestones.

Leon
That’s it. It’s about getting people back in at that decision making process and saying, well, look, realistically, there’s a limit to how many hours we can work before the quality just drops off. But we’ve got to go through these processes. We’ve got to go through QA, for example, or there’s things that are out of our hands – say we’re submitting to the app store.

So, it’s not about trying to do less work. It’s about saying, here’s the plan to get to that point. Let’s prioritise the things that are going to add the most value. Getting stakeholders in at that point allows them to have their say and inform that plan.

Sara
When we were trying to line up two major deliverables we’ve got this year, I already knew three months ahead it was going to be really tight. We just don’t have enough people. The hiring is tough for technical stuff right now, I’m pretty sure everyone would agree with me on that front!

I remember going to the leadership team, and explaining, look, here’s my idea. Can anyone help me? Can we, as a leadership team, come up with a way to try and make these two things happen? The input from them was incredible – have you spoken to this person, have you thought about pushing your team in this direction?

Leaning on them and being vulnerable and saying, look, I don’t have the answers, but here’s the things that we want to do as a company, was really valuable. Here’s some ideas I have, let’s figure it out together. Then they’re also bought into the plan and the idea, because they’ve been a part of it.

‍

"It's really hard to prioritise when you don't know what's going to come up in the future. You've committed to doing this thing in six months' time, but something more important has come in… it's impossible, right? There's no framework in the world that's going to allow you to do both those things."

Leon Barrett, Product Director, 383

‍

Leon
It’s that understanding and the buy-in. Yes, there’s going to be fixed dates that we have to hit. It’s not about saying we can’t hit that date. It’s saying, if we’ve got to hit that date, what do we then need to change in order to do that? What’s most important? What do we think is going to really happen? We’ve got all these features, but do we think on day one people are going to use them?

Once you go through that you can then start, then, really being iterative. That agility can’t just be a thing that happens at the product team level. It’s got to be the culture of the organisation.

Sara
It’s honestly believing that you’re trying to get to the same goal that they’re trying to get to. I think it’s a much easier conversation.

Leon
Absolutely. You’ve got to be able to hit those milestones, whatever those look like, in order to get that confidence.

Sara
There can be a tendency to say, agile, okay, we just do iterative sprints and that’s what we do. And if you really think about that… in what walk of life do you just go, well, actually this is going to take as long as it’s going to take. That’s not an answer!

Leon
“What will I get?”… “I don’t know. We’ll figure it out when we’ve got it.” It doesn’t work! That is one of the hardest things to explain to people when they ask what it means to be agile.

I remember years ago, we had a client who had not done anything agile before. They were looking at a new venture within what was a very traditional organisation, one which had government contracts that would last 20 or 30 years, and it was all mapped down to precisely what was going to be spent each year. And they were trying to do that with agile. So, what’s going to happen in sprint one? What are you going to do in sprint four?

‍

"Agility can't just be a thing that happens at the product team level. It's got to be the culture of the organisation."

Leon Barrett, Product Director, 383

‍

We got ourselves into a trap where we were trying to plot out what was going to happen in each sprint, right down to the features. We did the first two sprints and it was all right. In the next sprint, there were a lot of decisions that needed to be made by the client, and they weren’t made in time, and therefore we didn’t hit the sprint goal. At that point, the client saw the sprint as a failure. Fast forward quite a few years and, actually, what you realise is that the time it takes to think through something is the work, as well as the shippable thing.

That’s really hard to explain because I think most people have a concept in their head, and there’s a gap between their idea and the reality. How do you communicate that we thought, for example, login was going to be really simple, but actually there’s all these edge cases that aren’t quite as simple. Actually building the login didn’t take us that long, but that gap, there, to make sure we’ve thought about all those different scenarios, that took time. And that’s just as valuable as the finished article.

Sara
Because what people are picturing in their heads, often they’re not considering the unhappy paths, right? It works like this, and you log in, and then you see this, and then you point out, well, okay, but what happens if you don’t have a login? What if you’ve forgotten your password? It all starts to pile on.

Leon
Part of prioritisation is understanding, actually, how big is the task that we’ve got? How certain are we that we’ve covered all bases? How much is there to know?

There’s one framework that we use, based on a scale of certainty and uncertainty. Depending on where we are on that scale, can we start to plot what level of accuracy we’ve got, or confidence we’ve got, that we’ve covered everything off? This thing could start to grow from wherever we are now, so we can do two things; we can spend some more time now getting that knowledge, or we can start it and then know that, actually, it might increase.

That’s part of prioritisation – what can we do upstream to give us that insight so that we’re not committing to getting something done in three months when we don’t quite know how big it is. And then you get into it and you’re like, oh, actually it’s quite a bit more…!

Sara
On the other side, when you find you get your quick wins, I think that’s really important to vocalise as well – we thought this was going to take two weeks, it’s taken us two days. We’re going to take that time now and feed it into this other thing.

I think it’s good to call those things out as well, so senior leaders see that it’s not always, this is going to take a bit longer. They also see, actually, we delivered this in two days and not two weeks. We’re really pleased with that.

Leon
The only danger is, when you keep doing that and the expectation is, ah, you said two weeks but it isn’t going to take two weeks…!

Sara
I swear Stuart does that with me!

Leon
Especially when you’re working in a way where you’ve got complete transparency – you can’t hide anywhere, right? You have to have that pragmatism where you explain, yes, we did do it quicker than planned, Stuart, but don’t bank on that always being the case!

You can almost be too good in some instances, right? Then it comes back to bite you!

Sara
Definitely! What I like that we’ve done recently, as well, is when you hit those unknown unknowns or those curve balls, we come up with two or three different options about how to approach them and we go to the business leaders with them. Then they really feel like you’ve thought about it and you’re trying to find a way around the solution. It’s not just, ‘we can’t deliver it’. It’s, here’s the different options and here’s roughly how long we think they’re going to take. That’s certainly worked really well for us recently.

Leon
One of the things that we sometimes hear (and obviously we’ve not had this with you guys!) is that the client doesn’t have time to go and understand that problem space. We can’t talk to anyone because we haven’t got time, we’ve just got to go and ship it.

Have you encountered that in previous roles – not having that insight and just going with whatever you think is right?

Sara
There’s a balance with that. Certain things, say if you’ve got a competitor and they’ve got a feature, you can almost decide there’s probably not a lot of investigation we need to do here. We know we need to have that feature because our competitor has it. Where it’s something new, we’re offering something entirely different, we need to really map it out and understand the different flows.

It’s making that differentiation between areas that you do need to go and investigate versus those you don’t. We need to spend some time really fleshing this out because the problem space is new and it’s not really understood that well, versus, we already know this really well. We’ve already got a bunch of data around it. Our competitors are doing it. We can probably go with this. Because that’s still data driven, right? That’s not just gut. That’s still data driven.

You can also have a hybrid. Say you’ve got a competitor doing some things but you want to do it slightly differently. Let’s take what we’ve already learned or what we already understand and then do research based on that and use that to ‘speed things up’, if people think it’s moving a bit too slow.

These things do take time. They are part of the process and the understanding of what you need to deliver so that you get a better product out at the end.

Leon
It’s that mindset shift, isn’t it? From, we’ve got a deadline so we’ve just got to get going, if we do things then that’s going to get us close to our goal, to, are those things the right things, do we need to do all of them? Yes, it might take a week or two weeks but it’s so important, because we could save ourselves four weeks of development that we didn’t need to do.

There is a balance between prioritising that level of research work – and it doesn’t all have to happen up front, it can happen concurrently – and being able to start and say, look, we know this much. That gets us going. These things that we’re not too sure about, let’s now refine them.

One of the things that we hear a lot from clients is ‘we’re trying to prioritise research, and we did some research two years ago… we haven’t got time to do any more, we’ve just got to deliver.’ And it always scares me! I’m thinking… what are you delivering?! How do you know it’s the right thing? Whether it’s adding any value whatsoever? You could be spending too much time on stuff that doesn’t matter, and you could have done that in half the time.

Sara
I like the concurrent approach. For example, we know we need to bootstrap the setup, the infrastructure, we know we need to get some AWS instances running, we know what technology we’re going to be using. Let’s go and do that, whilst we’re also doing this research in parallel, because that feels really efficient, like we’re going to get a good outcome.

Leon
It’s about filling in those unknowns, right? I think it is fine to commit to a fixed deadline as long as you’re flexible on the scope.

The flexibility, then, is in looking collectively and asking, well, do we not build a feature? Or do we have a slice of a feature that we’re going to deliver later? That’s where prioritisation comes in. There’s always going to be a point where it gets to crunch time and we’ve got to pull out the stops, but at least we’ve reduced down all of those different blockers that could get in the way of us getting there.

Sara
When you’re de-scoping, another thing that’s been quite beneficial for us is asking, how can we deliver that feature without actually involving tech? Can we harness marketing? Are there tools out there, SAS platforms, that we can use initially to deliver that functionality? It might not be perfect – it almost certainly won’t be perfect… – but it’s delivering that piece and giving your development team time to do the other side. So even if it’s de-scoped, is there a different way that we can deliver it that doesn’t involve building, or is only a small portion of the build?

Leon
Absolutely. I think that is all of my questions done. It’s been brilliant!

Sara
Always a pleasure!

Leon
Thanks for joining us. I hope people have found some useful bits there. I think the main thing really is, yes, read the books, use a framework, but it’s about communication, stakeholder management, empowering your teams so that everyone is aware of what’s going on and why you’re doing it, all the way up and down the chain. And it’s being realistic with what is achievable and what’s going to really add value. That would be the key takeaway, really.

Sara
Yeah, definitely!

Leon
Awesome. Well, that’s us done. Thank you and see you on the next Byte session!