Timestamps

00:00: This week's Squiggly Careers podcast is audio only

01:46: Today we borrowing brilliance from Nesta

02:55: Difference between experimenting, prototyping and improving

11:55: Stage one:  Do the groundwork

17:42: Stage two:  Build the specification

24:27: Stage three:  Test and iterate

33:24: Stage four  Learn and decide

38:43: How much buy in do you need before you prototype an idea

Interview Transcription

Sarah Ellis: Hi, I'm Sarah.

Helen Tupper: And I'm Helen.

Sarah Ellis: And this is the Squiggly Careers podcast, where every week we borrow some brilliance from a person, a place, an idea, and we try to turn that curiosity into something useful for you and your Squiggly career. And this week is audio only and is feeling a little bit different to record Helen. Why might that be?

Helen Tupper: That's because we're in New York, which is to launch the US version of our new book, Learn Like a Lobster. So far so good, except we have arrived in New York to the biggest blizzard in 10 years in New York, and it's an adventure. We didn't know if we were gonna get here. Now we've got here and we can't get very far. But it's, you know, it's fun. But it has changed how we were going to record the podcast. So for anybody that normally likes to watch it, sorry, but we don't. We don't look our best. We've been for a walk in Central park, we've been snowed on.

Sarah Ellis: I fell over in the snow, down some steps.

Helen Tupper: Whilst commenting that her shoes had more grip and then to break an umbrella.

Helen Tupper: It's been a lot of fun, everybody.

Sarah Ellis: But if you do hear noises. And there are massive chunks of snow falling down outside the hotel that we are staying in because it's really high up. So if you do hear occasional, like, thuds, that. That's just what that is. It's just like snow will occasionally just hit the window. So it's just. It's very memorable.

Helen Tupper: Bear with us.

Sarah Ellis: At least not boring.

Helen Tupper: Yeah, it's not boring if the audio isn't quite where it normally is. If you hear weird noises in the background, you know why. But we never think that that should get in the way of learning. And so today, today we are still committed to helping you with your squiggly career and your learning. And the topic we're going to talk about is prototyping. And we are borrowing brilliance from Nesta, which is an organisation that Sarah and I have followed and admired for time. They just produce a lot of really useful templates, tools, they do brilliant research, really broad range of things and they have a very good 52 page document which talks through their prototyping framework. And we wanted to talk about the framework and bring it to life for you because we think it is quite useful for everyone to use in the context of their careers.

Sarah Ellis: And we've even just been for breakfast in New York because somehow some of the cafes are open, although I don't quite know how. I don't know how those people have made it to work. And we even spent that whole breakfast talking about prototyping. So we are so committed to the squiggly cause. After falling down in the snow and going to Central Park and seeing the Home Alone Bridge, I think it was a Home Alone bridge with lots of snow around it. We did then still talk about the podcast. So it doesn't matter where you are in the world. We're always thinking about Squiggly Careers. And a fair bit of that conversation we were talking about the difference between experimenting, prototyping and improving. Because I do think, like we always say, the words that you use make a difference. They help us to interpret and to understand the job to do. And I think sometimes it is good to debate those words. You might just be like, oh, it's just semantics. But I think the reason that it's good to have those conversations, like in your teams or just with yourself, is, are you talking about the same thing here and is it just a different word for the same thing? Or do we think there's something different? Because when we started off talking about experiments versus prototypes, instinctively I think we both felt they were different, they weren't the same. But it took us a little while just to almost like, pull them apart to kind of go, what is it that feels different? So perhaps if I explain how we see experiments and then Helen will talk about how we see prototypes. And this is not in the Nestor guide, everybody, they just go straight into, like, how to prototype in quite a practical way that we will talk through. But I do think it's important that, you know, you start off slightly more zoomed out and you just sort of connect the dots between some different things that we often talk about. So the way that we see experiments, and this is just how we also use them in our team and in our work, is experiments start with an unknown and they can be fast, quick, easy. You can sort of get started with an experiment today. If I wanted to experiment with how to reflect for five minutes a day today, I could just do that. I could have a hypothesis. I could just start experimenting. They're sort of fast, flexible, and often quite easy to get started with. And you don't need to have done very much work beforehand. I think you can sometimes you might do. But in a lot of the cases, I think you can experiment. The sort of barriers to entry, to getting started are quite low.

Helen Tupper: And I don't think with prototyping it's that the barriers to entry, or maybe it's just. It's a much more considered process. So we can decide to prototype something, but there is a process to follow that is more likely to make that prototyping effective. And we're going to talk through the process. But as Sarah and I were reflecting over breakfast, I mean, people that sit near us while we're at breakfast must think, well, they're having a very intense conversation over some avocado on toast. But we were saying, oh, actually we probably do. We do a lot of this process for prototyping, quite a lot, but we do it in a roundabout way. I don't think we don't always get the value from prototyping because we kind of do it informally and there is just a little bit more of a process to follow for an effective prototype versus an experiment. The other thing Sarah and I talked about as well was sort of continual improvement. So the way I see this in my head is a triangle, obviously, because I can only think in frameworks, but I sort of see that you have continual improvement, which is, you know, small changes that you make to make something better basically at work, and that happens. And then you have experimenting, doing things you've not done before to get some kind of fast insights on it. And then I think you have prototyping, which is a more considered process, and there tends to be an element of building in there and anyone can do. And there are loads of different ways you can do all of those things in your squiggly career. It's just we think that prototyping, if you've not done it or considered it before, there are some benefits of doing it in a. Well, like following the framework, basically, what we're going to talk through. There are some sort of. I don't want to say the word structured because I don't want to put people off, but there are, you know, some stages to how to prototype effectively, which we're going to talk through today.

Sarah Ellis: And actually, when I was using Claude to ask these questions before we had our conversation, which is always why I think you should do both, it was a good example of the critical thinking that you and I did was actually more useful than Claude. So good to know. Thank goodness our brains are still helpful.

Helen Tupper: Not replaced me yet.

Sarah Ellis: Not yet, it's still, I'm still building in the background the Helen bot, which will replace you still. That's going to come. That's my 2026 goal. But they, they Claude said experiments are about learning, whereas prototypes are about building. And actually just listening to you there with like the words that you used, I probably wouldn't be as. I think that's almost too simplistic because. Do I think you learn from prototyping? Yes, but I do, I do see that as like a use. It might, it's almost like a useful starting point for a discussion. Whereas, you know, you're always testing our hypothesis with an experiment. I do think with prototypes you do have a more of an idea of what you're trying to build, but there's still, you're just like, oh, but I'm not sure which bits are going to work and you don't want to over commit time or money or resources because you're not quite sure. There's still unknowns. So I do think they have kind of quite a lot in common. But I think almost the examples and the situations where you might use one versus the other end up being quite different. And perhaps that's a good, a good thing to talk about in your team. If you were to kind of go, well, how good on a scale of 1 to 10 do we think we are at experimenting, prototyping and improving on, on that scale, where would you be? Because actually I think that's a good reflection of okay, well why are we better at one of these than the other? What would you say, Helen, for amazing if where are we on experimenting versus prototyping versus improving fewer doing scores out of 10?

Helen Tupper: I think we're good at incremental improvements because I think we're constantly kind of challenging build. I think you and I are sort of quite critical and we're quite involved in our business. So I think we're constantly sort of challenging and building better experiments. I think we are good at that too. I'd say kind of very good. Continual improvement, good at experimenting some room to do that better. And I think we are not good at following a formal process of prototyping. I think there have been examples of when we've done it, but I don't think we started that going, this is going to be a prototype and we're going to go through these stages. So that's how I would rank them. What about you?

Sarah Ellis: Yeah, in my head I'd gone in that same, in the same order like improving experiments, prototyping and I sort of gone 8, 7, 4 to 5 out of 10 because I often find scales are a useful starting point to then go, okay, well why would prototypes be the bottom? Like you and I have both put it at the bottom and what is it that we are not doing? And as you described, I just don't think we're intentional enough about prototyping. So then you do miss out on the value. I think we sort of do a half a job on prototyping. I think we've got a lot better at experiments because we wrote about experiments in Learn Like a Lobster. We did a whole chapter on it. Particularly easy and everyday experiments. We've more built that into our team ways of working. You know, we have an experiments channel in teams and people across the team share the experiments that they're running. They're sharing what they're learning. We're really big fans of the work of Anne-Laure and her book on tiny experiments. And I can see that our team really like her work too. And that's it's kind of captured people's imaginations and really stuck. So I think we were probably a five to six on experiments and I can see that that's nudged up maybe one or two over the past 12 months. And so I think our prototypes would be our biggest work on it of those three. So again, maybe a good discussion to talk about as a team.

Helen Tupper: And I think that's a really good point. Like prototyping as we'll go through the different stages, it is a team process because the amount of people involve in it. And I think the more you do this together and everyone starts using the language, the easier this is. So there are four parts of the framework that we're going to go through, so I'll just say them. So you've got kind of the structure in your head and obviously if you want to look back at this afterwards, we've got the pod sheet, which is a one page summary. You can download that from our website, amazingif.com just go to the podcast page and you'll find it. But the four parts of the framework are one, doing the groundwork, two, building a specification, three, testing and iterating and four, learning and deciding. And if any of that sounds a bit scary and formal, don't worry, it's not. We'll talk through what each one means. And we thought we'd try and bring it to life with an idea that has come to the Amazing if team actually from Katy Barnes, who is a definite squiggly supporter who had sent a picture of her diary, which she'd sort of hacked to become a squiggly development diary. So it was a hard diary, like one of the ones that you have for the year, and she'd put in for every week a squiggly kind of prompt. And it sort of led to this idea of, ooh, could we, could we, should we? Would we create a squiggly career development diary for our audience? That is a TBC question. But we thought it would help to take this prototyping structure, apply it to that idea, just to bring it to life for you.

Sarah Ellis: So the first part, which is doing the groundwork, the bit that really stands out for me here, because I think once you've got this, it's also something you'll keep coming back to, is what's the problem we're trying to solve? And I always like that as a starting point for lots of things, for processes, for projects. So kind of being clear on that. And then once you know that problem connected to that will always be, well, who are you solving for? So make sure you're clear on your customers or internal people. I liked this question that Nesta put in the document. What assumptions are we making? I just think that's a really helpful provocation because everybody saying their assumptions out loud, rather than assumptions going unsaid, I think also gets people's. Encourages people to sort of hold their starting point quite lightly, you know, because otherwise, if those assumptions are just. You keep them to yourself, then they probably influence even maybe what you might build or what you might test or even the questions that you ask. So for us, Helen, if you were thinking about this, like, what are some assumptions you would be making? If we were doing a squiggly career development diary, what would you be writing on the wall?

Helen Tupper: I'm assuming that it looks like pretty much the picture that I got sent. So it's a physical diary. I've made that assumption. This is a physical diary. I have made the assumption that it's for a year, whereas actually it could be for a quarter. Maybe people get bored of this stuff, so it could be a quarter, but I've made the assumption it's for a year. I've made the assumption that people would pay for this, a want to pay for it, and it will be something they would buy. Because I'm thinking, oh, this is something that we could sell to our audience. And I think I'm probably also making the assumption that more people than Katie want it. Like, yes, our community definitely wants something like this. So there would be some of my very early assumptions that I'm making.

Sarah Ellis: Yeah, interesting. So one of my assumptions was it would be something that you would plug into your work diary, as in on like online, your Outlook diary. We both use Outlook or your Google Calendar. So I, and because also obviously I hadn't seen Katy’s picture so that was probably a bit of an anchor. So I, I don't know what that is. So when you said to me, because I was, I was preparing for this, oh a development diary or a calendar, I was like, oh yeah, so something we would somehow have as like a plugin or a co pilot plugin or something like that. So I'd gone kind of tech first. I suppose this kind of idea of adding it in so that then makes it harder to pay for, you know, when you're like, well how do you, I don't know how you charge. I mean obviously you can charge for apps and stuff. I, I think I also have an assumption of, I was like I'm definitely not sure yet if this is a good thing, you know, like as in, I suppose because I don't use. Again an assumption I have is I don't use things like this. So I would never buy a journal or I would never buy a physical diary which I know some people still do have. Like you still have quite physical things. So also probably one of my. Oh is that the things. And it's not just probably assumptions, maybe it's things that just go and said is I'm probably quite sceptical of this idea. Like I'm not, I'm not sure about it yet. I'm definitely not bought into it and I wonder if that's also quite useful to have, you know, if you're doing this as a team, just being like there's no right or wrong here but how, how almost like how bought in are  we all feeling like today and then it doesn't matter. It doesn't matter if you're, you might be a seven and I might be a three and that's fine because that's the point of prototyping as long as you are open to learning, listening all the things that we're then going to talk about. But I do think it might be quite helpful to like hear that from a group because I've worked on projects before where I think people might have started at a three but no one said it and then actually that creates issues like further, further down.

Helen Tupper: It's quite good to track as well as you go, isn't it? Whether with the subsequent stages, whether any of the evidence or data you get back from the other stages changes how people feel about it. I also really liked, because you and I haven't talked about some of these questions in the context of the idea of the development diary. I think it's quite useful if you're doing this as a team, like give people five minutes and a stack of post it notes and then you write. So you answer the questions like, who are we solving it for? What's the problem? What's the assumptions we're making? What else available you? Or 5 minutes to fill those out. You put the post it notes up and then you could kind of cluster them and you could obviously do this virtually or in person, but you cluster them to see like, where are things similar. Like we, we might have said, oh, we say we're solving the same problem, that, you know, development needs to kind of be in your diary if it's going to get done or something like that. Yeah, but then we might have ended up with some very different things. You know, the format of it, ours are very different and I think if you say it out loud, you might influence somebody's thoughts. Whereas if you give, you know, a quiet five minutes, you're probably going to get some more distinct ins for everyone. And just one other thing before we move on to the next part of the framework that I thought was useful that Nesta mentioned here, which is the who do we need to involve? And I think this talks to Sarah's point around, you know, people might have different levels of buy in. I think it also, as you go into the next phase, it is useful thinking who outside of this team or this room could we bring in to sort of the prototyping group. So Nesta say you need a core team, so that might be the people that are kind of bringing the prototype to life. You might want a sponsor, so someone who's going to really sort of champion the project, maybe bring other people in and then also the critical friends. So maybe those are. They are not the people who are inside the day to day team or on the day to day project, but they are people who can be critical and offer a perspective so you don't get stuck in a. You know, everyone loves this idea and maybe is ignoring some of the outside perspective or challenge that might, might be helpful.

Sarah Ellis: So then we're into phase two, which is, I think my favourite of the four, which, if you're allowed to have favourites as part of a prototyping process, which is building the specific. So this is when you bring to life a simple version of the idea. And Nesta suggests a few different ways that you can do that. You can sketch, you could just sketch an idea on a post it note. You could design a web page. You could do a simple mock up of some screens or a process. Anything that you can do. I think it's almost. You're trying to take it from an abstract idea or concept into something that you can see and, and understand. And I've actually done this quite a few times with different projects where it's like, well, what would almost like what would the press release look like? I've done that quite a few times. What would a poster look like? We've done it a few times with books. What would a front cover look like? Again, just to bring to life before we got to learn like a lobster, we got quite a few book ideas. We always have quite a few book ideas. And again, you can just do the covers. Like what would a cover design look like? And it's not about a cover. You're not prototyping the COVID design, you're prototyping a concept for a book. But it's just a way that everybody can understand that you can sort of see it and talk about it.

Helen Tupper: I have them in like past innovation teams that I've been in. Like back in the day when we used to launch apps and things, you'd often like do mock ups of pages of what the app looked like. And people might think this needs to be really advanced, this needs to be like a storyboard or I need to have all the, you know, all the functionality in. You really don't. It's just, is just making something slightly more tangible than the idea that's in your head. And I always think it's really surprising how much conversation that can unlock. Like you don't have to have the whole thing mapped out, it doesn't have to be perfect. But just this is what it could look like. Here's an example of what a few of the web pages could look like. And you don't need to have all the copy on there. You could just have like some like sort of blocks with some pictures in there. And you'd say, okay, this would be where we did the about us section and here's what weather products would look like. So you don't need to make this perfect. I think that's really important for like building, bringing it to life. But it's to really make it tangible so people can talk about it.

Sarah Ellis: So here, if we were doing the Squiggly Career development diary. You would mock up a page of a diary, you know, a physical page of a diary. That'd be a really. A really obvious and easy way to do. To do that. That would also be really interesting just to see what people did, you know, because I'm like, when people imagine what a diary looks like now, like what's in everybody's head. And at the same time, what you might do is like, we'll mock up what this would look like if it was in your calendar, your work diary. And so maybe you would get everybody to do those, because those two things are already quite visual things. And I think if you got everybody to do that, you'd be like, oh, you know, for the one that's in your diary, like your work calendar. Some people are very into using colours. I actually saw somebody when I was with Asda the other week and they showed me their diary. It was very colour based. And so maybe because lots of people associate squiggly with yellow, maybe it always goes in as yellow and maybe it's always the first 10 minutes that you're at the start of your day. Maybe it's always 9 o'. Clock. You always see that 10 minutes of yellow. And maybe there is a prompt or a question and that's. I don't know if that's what that looks like, but if I was building it, that's what I would be drawing. I'd be drawing a My Monday. I'd be drawing that box. I'd be making it like a colour. I would put a prompt in there as an example and then I'd sort of write times five, because you're going to do that for every day. But then somebody else might prototype that in a very. That might be really different to what other people had imagined. Maybe other people had imagined. Oh, I thought it would be something that you did on the first Monday of every month with. In a team meeting with everybody else. In my head, it was a joint development diary. It wasn't just for you as an individual. And you'd be like, okay, that's really interesting. Who is this for? Is this just for individuals or is this for teams? That's a really good question. I like this phase.

Helen Tupper: I know I like this one. But even again, I think, and I hadn't thought this before, I thought, oh, there's one prototype. But I also really like the idea of giving people, like a day or two, like to create a prototype, like either a sketch or a screenshot or something, and then comparing and you need to come at the end of it with like, okay, so this is the one that we're going to take into next phase. But having some like, tangible, oh, it could look like this because I really hadn't seen it as yours. I love the idea that it's like this yellow moment in the day. Just to add another thing that I really like that Nesta did. In case anyone's thinking, oh, that Helen and Sarah are talking about this diary. But I, I want to launch a new service thing or something for your business. They also use Lego men in the. They've got this picture in the document. It's really. I think they've got a shoe box and there's a service that they're. They're. They were kind of building a specification for. But you could just like use a leg and imagine it's like employees or it's customers physically going around and saying, oh, this would be the journey that they would go on and spend time here and then they would go here and it. Again, it's that simple. You can have a piece of paper that you draw the, I don't know, the flow on and you just move your Lego people around as if it was customers or employees or whoever the audience is. But it's just a way to bring it to life, to kind of have a conversation about it. So just be. I think the more real it becomes, the more useful insight you're going to get from the prototyping process.

Sarah Ellis: And I think the watch out and see. I don't know whether you read something in the nested document that helps you with this is. I think this is sometimes where I get stuck because I like this bit. So I could just keep coming up with ideas for what this would look like. But I suppose there is a point where you've got to stop building specs or like ways that this could work and you have to start testing it. And so I think it's probably just if you're leading this process and you probably do need somebody ultimately accountable for sort of like leading everyone through the process going, okay. I think each one of these stages needs to have quite a distinct start and finish. Like when I was reading it, it felt like they were a stage and you knew what stage you were in. And this is probably where we sometimes go wrong at Amazing. If is like we don't know what stage we're in and we don't know when we're moving to the next stage. So you and I have quite a lot of conversations, I think about this Phase where we have ideas and we're like, oh, it could be this or it could be this or it could be that. But then the next phase for. So phase three is then testing and iterating. Like you've almost got to go, I'm going to stop, I'm going to stop building and start testing. So Helen, where do you start with testing? Because I think you've done some interesting work on the podcast actually around testing recently.

Helen Tupper: Is there a few ways again that Nesta have sort of advocated that you can do this testing and iterating phase of it. So the important thing is you're taking it to real people and I think that could be potential customers. Though I also think it is useful to take it to people who almost from the outset wouldn't be potential customers. Why wouldn't you use this? So I think their insight is also, you know, I think sometimes detractors, their critique is actually just as useful as the people that are like, yes, I'd love, I'd love to do this. So you could do like a co creation session. So you could get some people in a room or on a zoom and say, you know, this is what the development diary looks like. For example, build it better. Like what do you love? What would you move Again? I quite like think if you're doing this, if you're, if you are in a room, I would just get like a big piece of a three. For our example, for example, I'd get like a big bit of a three and I would have all the features like on a post it note and I would say like move them around, take out what you don't want, add a new feature in so that some people feel like they are, they are creating it. But you could do exactly the same sort of thing on like a mirror or just as long as lots of people can be in the same document, can be on the same, the same thing that they're creating. We've talked about challenge and build before. So what do you like? You might say keep and kill. What do you want to keep? What do you want to kill? The reason I like challenge and build is it's, I don't think it's as binary as keep and kill. I think it's got a what's not working and what would need to be different for that to be better, which I, I think has more learning involved in the process. Also, like just give people the opportunity to use it for a week and come back because I think there is all there's. I always remember that stuff when I used to work for Procter and Gamble, and there's like the first moment of truth thing, which, when someone sees it, like, oh, I love that idea, I love it and it's. Or I hate it. Or, oh, I don't get it. Like, first moment truth, really useful. But then second moment of truth is what happens after. So when they use the product and then that is often a very, oh, it's better than I thought it was. Or I really like the COVID or I really like the concept. But actually when I started to use it, it just didn't really work for me. And so you kind of want. I think if you get. You can get feedback in a room on the day, but when people go away, I think that insight is really useful too. That build. Just building in a bit of time.

Sarah Ellis: Yeah. Here. I think, actually, I almost think you get quite different outputs depending on how you test. And if you only test when you're there, I think it's always slightly. I don't know you, because people will ask you questions and it is quite hard to not explain. Whereas I've always found it fascinating when you create something and then you just don't explain it. You know, you just go to. Let's say we were doing the diary idea. You give people. And let's say it was the one in your. In your calendar. So the tech one. The way that I would test and iterate, I.e. i would give people one page of instructions and then get people to test it for two weeks, but they can't talk to you. And so, like, did the. Did the instruction. Did people fall at the first hurdle? Did they even. Did the instructions even make sense? Because that's where you've got things like, oh, I thought it was super clear. And then someone else is like, oh, I didn't get it when you said a yellow box. I don't understand. I don't understand what you mean by that. Or. And then actually when people have done it for the two weeks, you know, did they. Did they stick to it for the first two or three days and then actually lost a bit of interest or something more important came in or actually, was that. Was the reminder helpful? But actually people want the flexibility of doing it at any time in a day. Like, if I think about the. My own way of those kind of things, it's very rare that I do the same thing at the same time every day. I don't find that very appealing. So I can imagine if I was testing it, I might be like, I do Want it in my diary at the start of every day, but I don't want the expectation of I must do it between 9 and 9, 10. But then does that mean I don't do it? So, you know, like, I think that's here where. Where they're talking about testing and iterating. They want it to be. I know it's always a funny phrase, isn't it? Like real life. Because you're like, well, the other life isn't fake life. But, you know, like it needs to be as close to the. What you're imagining as possible here. I think in terms of if you wouldn't be part of whatever that prototype is when people are experiencing it, you need to take yourself out of it. If you're not going to be there to answer questions or explain, you have to just let people experience the process, the project, the idea, whatever it might be and like have a play. We're finding it now with. We've got two tech products you could. Sounds a bit lofty that you. That you mean you could call them that. That we've launched in the last six months. So we've got our Learn Like a Lobster profiler. You can still both go and have a play with both with these if anyone wants to. They're both free. And then we've got a say the Hard Thing GPT. And I think we are in unintentional testing and iterating at the moment because we haven't designed this like a prototype. We probably would have been better because of it if we. If we had done. But we are. We have just put those out there. You're not. We're not there as people are using those GPTs or using that profiler and people are getting in touch with us and letting us know the bugs or what's missing or what's not working. And so we're sort of live testing and iterating probably with people who are interested rather than like you said, like the cynics, because that's probably how they're finding it. And so they also want to be helpful, they want to help us make it better. But I think we are definitely getting feedback that I couldn't have imagined or anticipated if it wasn't some people at Cambridge University using the say the Hard Thing GPT and then literally sending us a list of seven bullet points and going, have you thought about any of these things? And this is sort of what we need and we really like it, but we can only use it if you think. And I just looked at that list and thought we've not had a conversation about a single one of those things. And that's so, so useful for us to then think about, well, how do we build it better?

Helen Tupper: I do think there is an important skill as well at this stage, because if you are, let's say you're the person who's leading this. I think the skill is we often talk about like saying the hard thing and hearing the hard thing. I think, think you have to, you have to be okay hearing the hard thing here because some people are going to say, I don't like it. I think I used it and didn't work for me. And you might want to defend your project at this stage and be like, well, that the reason we built it like this, or you're not our target customer or whatever else is in your head. And I think you have to get really good. Your aim here is to listen is to create something that is then used by other people. And your role is to then listen to how they engage with it. It is not to defend the concept or the idea or the product. And I do think that's a skill because the longer you work on something and the more you believe it, the harder I think it is to hear somebody else be critical of it, which is what really testing and iterating. You're inviting that critique of your. And some of it might be amazing, but also you've got to be prepared that some of it, that won't necessarily be what you want to hear.

Sarah Ellis: Yeah, I think you have to. And I think I've learned this from experience. Detach yourself from what it is you're prototyping. You've got to make your prototyping not personal. Because we've both worked in jobs where I have created things from scratch in quite a prototyping type way. And I think I have made the mistake sometimes of connecting what people are saying about something. If it's negative, you know, they're saying the hard thing. And I'm connecting that with, they are judging me as a result. So this doesn't work. And then I jump to. And then that means you're not good at what you do. Whereas versus, this just doesn't work. And this is, and this is why I think the difference now that I have is, is I sometimes in workshops, do live, challenge and build on our work, where I am literally saying, what's one thing you'd change about this? How useful is this out of ten? And it is. And people are saying quite a lot of hard things about work. That we do. But because I've almost made it quite playful and I think I've detached my own sense of personal worth from what people are saying. Instead I just sort of find it. I'm just like, oh, this is really interesting. Those insights are really useful. So it's just one of those things. I think when you're reflecting on the different stages of prototyping, some bits of it might absolutely play to your strengths. Like I think when I'm the building bit, I'm like, I think I place to both of our strengths. I think this bit is almost. I've had to do some unlearning and relearning. I've had to learn to be, to be better at this bit. And then I just don't think I do phase four. So do you want to talk about that? I just don't think we do that. I think we ignore phase four.

Helen Tupper: Phase four, Our breakfast with reflections are that phase four is probably the biggest gap for us to work on if we want to get better at prototyping. So phase four is learning and deciding. And I hate saying that because obviously learning is so important to us. And I do think we're good at the learning part. I think it's the deciding. So let us tell you what nest to say about this stage. So they say that this stage four, which is like the final part of the sort of prototyping process is that you review what you've learned and you choose the next step. And I think that we are good at reviewing what we've learned. I think we regularly kind of go, okay, what we learning, what's working, what's not working? We, we do that in that I think that's sort of like the improvement thing I talked about earlier. That's a continual way of us thinking. But I don't think we often formally decide on what we do next. And so as a result maybe some things sort of start and then they just sort of like, I don't know, they just sort of dwindle away. Like I remember ages ago I started creating like the, you know, like, I forgot what I called it, but like a squiggly career survey thing. And I was like, oh, I kind of started it, but it's not because it's not got a team around it. I've done like two iterations of that. But I think because I've tried to do it on my own and I've not got a team around it. It's not had both the formality and the support to kind of get it going beyond that. And then it sort of just dwindles away. We don't decide, do you know what, we should stop that now. Because the reason it's not working is it needs a team. It's a good idea, but we just sort of let some things dwindle or there's not this clarity around what prototypes are in progress and what stage are they at. There's just not that view. It's just there's some initiatives that we've kicked off because we like the idea and we think there might be something in it and some of them might continue and some of them might not. But there's no.

Sarah Ellis: Which is that. Which is that profiler that tells you that you're not a completer finisher that we both did. So that's quite. It's really old school now. So I don't. I'm definitely not recommending everyone goes to do that. But when Helen initiators, I'm sure. I think. I can't remember which one I was. I think you and I were different. But what this talks about is really old, by the way, everyone. So please, if you could have gone do it, cheque that it's still valid and useful. But it did talk about the roles that you play in a team. Helen and I were both like the initiators or plants or those which are basically like, you come up with ideas, you grow ideas, all that kind of stuff. And then it sort of told you, like, which is the one that you're both sort of worst at and not both of us, but like this obviously as. As individuals at the time. But neither of us are complete, what they call complete to finishes, which is essentially, you know, like, I often. I often think it is like the hard bit, you know, it's the last 10% right. Of going the due diligence here of not only what have we learned, but then what does that mean for us in terms of the decisions we are going to make? And like Nesta used the words, to move forward, you need a business plan and measurement. And I think both you and I'd be like, or shall we create another prototype for the business plan, our measurement. And so this is where I think, you know, back to. And we all. We all know this is true, but when you have a range of people around a prototype, I suspect then it. It almost protects against. It doesn't sort of. Everyone will be good at the kind of different stages, and it protects against not doing a part of it. So some people might skip past the idea bit because maybe they tell themselves they're not good creative thinkers and they just go straight into testing. They're like, oh, we've got one idea, that's enough. Whereas you. And I'd be like, one idea is never enough, let's do 10. Whereas some. Maybe some people find the testing a bit harder because perhaps, like me previously, you're like, oh, no, But I'm quite attached to this now. I don't really. I don't really want to hear what people think. I'm going to go straight into deciding this is the right thing to do. And perhaps you skipped that. So I think just knowing, you know, across your team, I almost wonder whether, yes, you do need one person accountable for sort of overall leading the prototyping process. I suspect you don't want too many cooks or that just gets confusing. But knowing almost like, who to draw upon in terms of people's skills and strengths. Like, we've got somebody new who's just joined our team, where I know she is. She would. She will be good at this bit. Like, she's naturally good at data and process and operationally also really strong. And so I think. And actually we've got somebody on maternity leave who's also good at this. So, you know, she on maternity leave at the moment, but when she comes back, she. She's good at this as well. And I think when you know your teams and you know each other well, you can sort of ask people to play a bit more of a part in those sections just to help you to kind of make sure that you've gone through it properly. Because actually, you and I were struggling when we were over our prototyping breakfast, as I'm now calling it, we were struggling to think of an example of where we'd seen a prototype through. We actually couldn't quite. We couldn't quite get to one because often we. What did you describe as, like, loose ends or, like, loose threads?

Helen Tupper: Yeah, we're thinking, yeah, loose ends of projects and things. I think we just kind of keep things going for a bit longer. Yeah, it's just distracting. And then I think you can't. You can't critique it enough. I was also. I had the same thought about, could you have a phase owner, almost like a relay, so you have someone that owns the whole process, but you might say, like, okay, so we're kind of. We're deciding now we're going to Move into phase, Phase four and that kind of this phase owner is. And it. I think that creates a bit of shared accountability in the team.

Sarah Ellis: Yeah, nice.

Helen Tupper: So it's not just someone pet project or favourite idea. And then you go back to, you know, the thing you said at the start about kind of how bought in are people to the idea. That could also be like, where. Where are we at in terms of buy in? Has it changed?

Sarah Ellis: Are you and I going to fight over being in charge of phase two? I want to build the specification. No, I want to build it 10

Helen Tupper: out of 10 on the Squiggly Career development diary. And Sarah's like, I'm a 1 out of 10 and we need some kind of adjudicator for the, for the debates that will follow. But it is interesting, isn't it, though? Because if you've got like, I do think you could get to a stage of the prototype where you've had really good feedback and I think this would happen for Sarah and me. We could have really good feedback on an idea that we've got. But actually we might have low buy in because we might say, well, it is a good idea, but it's just not the right thing for us to do. Like, there's definitely, you know, you can't, you have to. If you're going to go beyond phase four and take something forward from prototype into something you're actually going to put into some form of production, whatever production means in the concept of your idea, you know, your, your buy in and belief in it is just as important as people saying, yes, this is something we want, because if they want it but you don't want to do it, then it's not, it's not worth doing.

Sarah Ellis: I also think there is, if you're doing this properly, having looked at that document and when we've been through this, I think you want to be very intentional and make some really clear choices about where you prototype. Because if you prototype badly, you get some of the things that we've described today and that almost feels like a waste of work and a waste of effort. So you want to prototype well, but to prototype well. Certainly the conclusion that I've come to like exploring a bit more. It does take a lot of. It's a lot of effort. Yeah, it's going to take, you know, you've got to involve quite a lot of people. You've got to go through all of these stages. Whereas, you know, we talked about you can do loads of like, easy, small experiments. I think there probably aren't loads of things that you want to prototype. Because if you do too many, I can imagine if we started to be like, let's prototype a development diary, an idea for a new book, an idea for some tech we want to build. You could choose to do. We. We could start doing a lot more prototyping than we do, but I am not sure we would want to because of the. Almost like the implied resource of what this looks like to do really well. And so I think you really want to think about what are the projects or the things that we kind of care about and that feel valuable enough to make the investment in prototyping. And actually that's what's really gone through my head as we've been thinking about it, because actually we have taken experiments and embedded that into our company in a way that I think is really useful. If we were going to now do the same for prototypes, I think a danger or a watch out for us would definitely be, well, I don't want to be prototyping loads of things. I probably want to be prototyping one. One thing at once maybe, or any ever. Maybe one project and one process. Just because then what this looks like.

Helen Tupper: I feel like I'll take that offline. I won't put us on the spot on the podcast, but I think it is like, what are your big bets? You know, what is something that is significant to the team? Your future strategic behaviour apps. I think those are the things that are worth post typing. As soon as we finish recording this, I'm going to give you. I'm going to give you the thing and we'll.

Sarah Ellis: We'll get started. Exciting. As long as I don't have to be in charge of all the different phases, then that's fine. I'll just do stage two.

Helen Tupper: Oh, yeah, you're on the. You're on the final phase complete to finish the skill development.

Sarah Ellis: Oh, imagine, imagine.

Helen Tupper: She looks excited. We will summarise the four phases as we've talked about them in the pod sheet. So if you want that, make sure you cheque out the show notes or go to the website amazingif.com also in the pod sheet, we will link to the full Nesta 52 page document, which if you do want to dive a bit more deeply or get it from their perspective, would recommend at least kind of flicking through that because there is a. You know, there's more detail than we've shared in the podcast today, but that's everything for this week.

Sarah Ellis: Thank you for bearing with us from a very snowy New York. We hope we know that you've not been able to watch it, and we are sorry that this week we've not been able to make that happen. But hopefully the audio's still been worth it. We are going to go away and warm up and work out whether we can brave the snow again later today. Thank you so much for listening, everyone. It does look a bit like Narnia. Bye, everyone.

Helen Tupper: Bye.