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!
