(simple electronic samba beat music) (electronic snare scratching) (samba beat thumping) (synth chords music) - 'Course I had a title here that was all around insight, and I was like, "No, you know what, "I'm gonna go with the bird poo." (some laughing) So I work for a company called BlueChilli, and we're a startup accelerator, and what we do is we take in early stage founders.
We give the access to a product team for six months, and we think, "In that time, "can we develop something that's gonna "reach product market fit?" As product managers, we kind of work on three products at a time, and we're really churning out, this entire time, what's the insight here, and then how do we turn that into product? So when I looked it up, an insight is, "the capacity to gain "an accurate and deep understanding "of someone or something", and the interesting thing about insights is it's not just something that falls into your lap. You know, it's not like the apple falling from your tree, and it's like, aha, insight.
People often thing that you've gotta be this great visionary to really come up with the insight.
Like you're the Steve Jobs, and you're like, "I'm gonna create this iPhone." There's actually a bunch of tools and techniques that we can use to be able to make better product decisions, so we're gonna go through some of them today. And I really liked this, "An insight is sometimes confused with incite." And I really liked that because, when you incite something, you're actually rousing action, and I think an insight incites behavioural change, so that's how I like to think of insights.
So we're gonna go through what insight is not. Data is not insight.
So insight is often used where people are like, "Grab the insights from your data," but data can tell you what people are doing, but it doesn't actually tell you why they're doing it. So it might give you a place where you can drill down to find insight, but data on it's own is not insight.
An observation is not insight.
Saying something like, "Parents want more me time." That's true.
There's nothing insightful about it, so there's nothing you can actually create a product around, until you know what's actually driving that behaviour.
When I used to work at Virgin, we used to call it like, "anec-data".
It's like, yeah, that's really nice, but that's just an anecdote.
There's nothing we can do with that.
And a feature request is not an insight.
You know we've all, we're product people.
We've got these product backlogs with features. A feature request or a wish list is not an insight, because you're not drilling down into the core behaviour of what's driving users to have this behaviour.
So today, we're going to go through finding the insights, some of the frameworks we use to really synthesise the insights, and validating that into product.
So, the founders that we bring in at BlueChilli are all subject matter experts, and this is why we choose them as the people that we're gonna invest in, because we're a really experienced product team. Like everybody on the product team has run successful businesses before, or like less successful businesses before, and we really look for people who understand their industry really well.
They live the problems day to day, and they really wanna be solving this problem, because, you know, without having that subject matter expertise, we're just a product team guessing at like, "I wonder what an architect's work flow is like?" So we bring in the product matter experts, but so saying, they all come in tied to a solution, so they don't come into us at boot camp and say, "Modern parenting is missing a village, "and parents are, like, killing themselves "trying to do everything to everyone." They come in saying, "We're gonna create an app "that looks up all the parents in your neighbourhood, "and it's gamified," and you're like, (scoffs) "Cool." "What problem are you actually solving here?" And then they try and kind of bring it back into our language, and they're like, "You get points for babysitting!" And it's like, "Okay, that's still not really solving the problems." So, they come in tied to a solution, and it's our job to really bring it back to that problem space, and figure out, well, what's the insight that we're working with, that we can turn into a product.
So we work on a Dual Track Delivery system, so we've gotta find the insight in the first place, and then we've actually gotta deliver on that and turn that into a product.
(some laughing) Has anyone here seen South Park? Hand up, if you've seen this episode.
Okay, for those who haven't seen it, Google it afterwards.
So there's the Underpants Gnome in South Park, and they are stealing everybody's underwear at night, and the boys track them down, and they find this cave full of underwear, and they're like, "Why are you stealing everyone's underwear?" And they're like, "It's part of the business plan!" They're like, "Well what's the business plan?" And they're like, "Phase One, collect these underpants.
"Phase Three, profit." "What's Phase Two?" And everyone's like, and that's our job as product managers is like we have to figure out, well, how do you take collecting underpants into this thing that happens and turn it into profit, and actually, as product managers, we would probably say, "Well collecting underpants isn't the solution," but (some laughing) that's our real role there is like how do we actually turn this thing into a business? So we take a very much Design Thinking approach, and I won't drill too much into Design Thinking, 'cause I'm sure, like, that's kind of the room over there, but we're basically taking it back to who are our users? What's the context in which they're trying to solve problems? And then we do a really fast prototypes, just to make sure we're on the right track. So we start of by trying to define the problem. We mine for the insights, so you know, saying something like, "Parents want more me time." That's really not an insight.
As a product net manager, we really need an understanding of where to look for insights.
And I was tryin' to talk about this with the other product managers in the team, because you can listen to all of this information, but for me, it's this real visceral reaction when you hear an insight.
It's like this real gut feeling.
I was tryin' to describe it, and I was like there's other ways you can then rationalise it, once you have this feeling, but I think, with experience, comes this kind of understanding of that there is an insight that we can work with, and we can use technology to solve that thing. And then we've got to actually harvest the insights, so, as I said, like, "Parents want more me time." That's not something you can work with, but then you can drill down into the why, like, what is actually happening to cause this situation, to give you something that you can make a compelling case to turn into a product.
So, there's lots of different ways that you can go about finding insight.
You know, there's looking at like data patterns.
There's like the Gartner Market Reports.
There's Google Trends.
I'm not a data-driven product manager, which is kind of much to my own disappointment. I wish I was, and in my mind, the only possible way that you can find insight is by talking to your users.
I know there's like the Steve Jobs and the Elon Musk. They're like, "We are the visionaries.
"We have the answer." Like, I'm not Steve Jobs.
Like, he's up there with his billions of dollars, and I'm here talking to you guys, (some chuckling) and so for me, the only way of finding the insight is to talk to your users, and really understand what's the context of which they're encountering this problem? Like, where are they sitting? How are they solving it? How are they feeling when they encounter this problem? Who are the supporting players? Like, we need to understand all of that before we can actually go ahead and say, "Well this is the product," where it's like gamification for babysitting. So we take a Lean Startup approach, and again, I'm not gonna drill too much into that, but we work in two-week cycles, where we build, measure, learn.
So for us, like the building isn't necessarily breaking code. It's, you know, we do a lot of lean experiments that are no code.
But every two weeks we look at, well, what do we wanna learn, and then we figure out how we're gonna learn that, so we're constantly learning and iterating along the way. So, in an ideal world, this is what the process looks like, as they're going through the product accelerator. You know, we kind of start off and we go through Problem Validation, and it's like, tick, okay we've got that.
Now let's look at validating the solution, and we go through that, okay, tick.
Now we can go into Development, because we've de-risked this, and we can develop it, and we can iterate it. So this is an ideal world, and this is kind of our, like, thing that we work towards, but more often than not, most founders have a little bit of a different journey, as far as timeline.
Like sometimes we spend four months tryin' to validate. Is this problem space exist, and is it big enough to actually support a business that's gonna pay you, and will people pay for this problem? And sometimes, we actually can't validate that. We spend four months on it, and it's like, "Look, we know that the problem is there, "but it's just not big enough a pain point "for people to pay for a solution," and in that case, we kind of won't go further into development. So, you know, you could look at it as a failure, but for us it's actually a success, because we've saved someone, you know, years of their life that they could have put into developing this thing and spending hundreds of thousands of dollars on developing this thing that nobody wants to use at the end.
So I wanna talk to you a little bit.
There's a case study of one of the startups I worked on, called TRIIYO, and Rebecca is, she's been in recruiting for about 25 years, and she saw this particular problem, and she came to us, and she's like, "You know, we've gotta create this content portal "that gives managers access "to legislation around pregnancy." And I was like, "Oh my fucking god, kill me. "This sounds like the worst idea ever, "because why would anybody want that?" And you know, when I tried to drill it down with her, it's like, "Well, it's empowering parents in the workforce," and to me, that's still like this nothing thing, because that's meaningless.
Like, every single company out there could be like, "We're empowering parents in the workforce." But when we drill it down into the problem, the problem that she was tryin' to solve is 50% of women leave the job that they're in within the first year of coming back from maternity leave, (throat clearing) and there's a number of factors that lead to this. You know, it could be that the job doesn't have the flexibility that they want anymore.
They could be feeling really disengaged.
You know, they're life has changed really dramatically, and work hasn't changed.
But we had to really drill down on, okay well, what is the actual problem here? So, we love our founders.
Our founders are amazing.
A lot of the time they're ex-corporate, so you know, they see this problem, and they're like, "I'm gonna create a startup," but they still work in really corporate ways. So Rebecca came to us and she's like, "This is what the roadmap looks like "for this content portal, "and these are all the features that it needs to have." And you know, I don't know about you guys, but I looked at this, and I was like...
Well actually, I'm gonna ask you guys.
Has anyone here ever changed their behaviour based on information you read on a corporate content portal? (some laughing) Just hands up. Hand up? Like nobody does.
It's like the fitness industry, right? You can tell people what they need to do, but they don't do it, because we're humans, and we don't do what we know is good for us. So I didn't want her to spend all her time creating out this corporate content portal that's just gonna sit on some internet, and someone from HR ticks, like, "Yes, we're doing something about pregnancy." Like that is not a useful startup, and that is not gonna change anything in the world. So we take it back to interview stage, and we did over a hundred interviews actually, and we looked at all of the players that are involved in successful maternity leave and then a return to work.
So you know, we talked to the HR Department. We talked to the Managers, women at various stages of pregnancy and maternity leave and returning to work.
We spoke to the dads, and we even spoke to women who are thinking about having a family, at some point in the future, to understand the context in which they're operating. And as I was putting together this presentation, I realised, we also should have interviewed colleagues of people who have been on maternity leave, because they're actually part of the ecosystem here. And so we wanted to look at what are the triggers for disillusionment.
Where does this problem actually happen, and what's the root cause in which women are leaving the work force, and then why is it happening? So, of the hundred and, kind of, 11 people that we interviewed, we had 71 different triggers that happened that caused this disillusionment at work and this disengagement and why they wanted to leave work.
And I'm actually just curious here.
Who here has been on maternity leave? Okay, and who has managed someone on maternity leave? And who has been a colleague of someone who's gone on maternity leave? Okay, so that's pretty much everyone, interesting. I'm gonna come back to you guys.
But from these interviews and from all of these triggers, we wanted to drill down and find out some of the patterns.
So, a great tool that we use for really synthesising insights is Trello.
So, when we do all of our research, our user research, we do our interviews, and then we set up each of the participants with a particular colour, and then every single piece of information that we hear, we create a different Trello card, and then we tag it with the colour of the person that said it.
So it's a really great way of very quickly looking at all of the research you've done and very quickly picking out the patterns of like, "Well, everybody says this, "and this is a pain point of one or two people, "but the majority of people, "this is the issue that they're having." And the number one insight that we picked up for this project was your experience on maternity leave has a one to one correlation with your direct manager.
Like, I don't know about you guys, but that like punched me in the guts, 'cause it's like, "That is fucking crazy." Like, you can have all of the policies and procedures in place from your company.
You can be so forward thinking and so empowering, and somebody over here has this particularly good experience, and you're in this next team over, and you have this awful experience, and that is crazy.
That's just crazy to me that that happens.
So we wanted to really look at, okay, well what can technology solve, and what is systematic societal change, because we can't kind of in or itself design culture, but as technologists, we can design processes and systems that could influence culture really directly, and create this behavioural change, and that's kind of the interesting part, I think, that we all work in as product managers.
So, we use a little innovation, kind of trick or hack called, How might we, and we saw this with Gretchen's talk this morning, with keynote, where she was like, "How might we do this?' you know, all of the kind of big companies really use this.
I think Google and Harvard, and I'm sure Buzzfeed has this, like click-baity, like, "These three words will change the way you do innovation." But it's actually really powerful, because, when we talk about challenges, we can sometimes use language that really limits our creativity.
We'll be like, "How are we gonna do this?" And just by changing the language slightly, it really allows for open brainstorming.
It's like, "How might?" it's like, well, we don't necessarily know that there is an answer to this thing, but let's all figure this out together.
So we looked at how might we spread the responsibility of a maternity leave experience to the whole company? Mind-blowing, right? So we came up with a lean experiment, and lean experiments are something that we'll do probably between five and ten times before we break any code on a product, and we do this to really validate are we on the right track.
We're doing this before we've invested too much time, because you guys know, like, once you've actually got developers creating the code here, it's so much harder to go back and change it, if it's not the right thing.
So we're gonna create our hypothesis, and we wanna validate this insight, and with this particular project, we had a developer knock up a Slack bot for us. It took like under a day, and luckily we had a couple of people on maternity leave at the time, and we created the Slack bot to basically say, "Can you use behavioural economics, "can you nudge someone at the right time, "and actually create this behavioural change?" So what the Slack bot did was the colleagues and the kind of besties and the collaborators of the person on maternity leave would get a ping every week that just basically says, you know, "Cheryl's out on maternity leave, "is there anything you wanna tell her "about what's happened this week?" And we found the whole company started using it, and it was really amazing to see what they're actually sharing, because they're sharing, you know, important information about the company, like procedural changes.
They're sharing gossip.
They're sharing staff changes, and this is all information that somebody on maternity leave isn't aware of, but that's actually what creates culture.
And so one of the problems was women were coming back from maternity leave. They'd missed all of the gossip for the last year. They'd missed all of the changes.
Everything's kind of different.
Nobody on-boards them to the changes, and there's this particular example here.
I don't know if you can see it.
It's like, Rosalind fell into the pond at the Christmas party.
I don't know if Chris is in this room, but he was there, and it was like this seminal moment in our company culture.
It was like, oh my god, like you were kind of divided into the people who were there and the people who weren't there, and shared experiences like this is actually what creates company culture.
And it's not the sort of thing that you would think to tell somebody about, like 11 months later, when they come back to work, but by them feeling like they're still involved in work, they're still aware of what's happened and what's going on, it's actually stopped that disengagement.
So I will say that this is a really unscientific approach.
Like, if we were a big company, we would have probably run this for six months. We would have had a control group of, you know, pregnant women who got this and pregnant women who didn't, and then got their MPM scores or NPS scores like six months later.
We're a startup, so we ran this for a couple of weeks internally, but we got enough data to say, "Actually, when you nudge people, "they will respond, and they will give an update." And we also got the learnings of, "Okay well, what's missing from this thing?" Like, this was a really quick lean experiment to say, "Okay well, if we build in a nudge, will people respond?" But it allowed us to say, "Okay well, what is missing from this thing, "and then what can we build out "for the rest of the product?" And we could really brainstorm, okay, well what else is needed here? And I promise you, in the brainstorming, not once did, like, a content corporate portal telling people about the legislation come out, but we did actually end up telling people legislation, but it's not like this core thing.
So, tryin' to sift an insight from general information is a really hard thing for our founders to really understand, because we ask them to go out and do research and validate things with their customers.
And so they'll go out, and then they'll come back, and they're like, "Oh, I got so many insights from that interview! "Like, caring for a parent with dementia is really hard!" And it's like, "Okay, and?" And it's like, "They want more help!" It's like, "Okay, "well we still can't build a technical product around that." And then our founders get quite frustrated, 'cause they're like, "I'm going out, "and I'm giving you like all of these insights, "and you're not doing anything." Because we really, really need to understand, like, what is gonna drive behavioural change before we can jump into building a tech product for that. So, a finding is something like, you know, women are disengaging when they return to work. There's nothing in that that tells us what causes the behaviour, so it's difficult to design anything to actually improve it.
An insight is so much more effective, because you've actually got a behavioural change there that can drive product development, so you can actually start to create core features around this.
So, to really kind of get to that insight, you've gotta keep asking why.
So in an interview, when you hear something, it's like, "Okay, that's interesting.
"Why is that, why is that?" And that brings us to the bird poo.
I don't know how many people in here have young kids, but I've got twin four year olds, and they're like, "Why? "Why, why why? "Why, why, why, why, why, why, why?" It's like all day long, and that's their way of really understanding the world, and we actually need to be a lot more like four year olds, where we ask why.
Because you know, often we'll kind of hear the very first thing, and we're like, "Oh, well that is the answer," but you really, really have to drill down to understand it. There's this story that I love to tell, and I looked it up to do this presentation, and unfortunately it's bullshit, but I'm gonna tell it like it's true, because it's a great story. (chuckles) So, there's these statues in Washington D.C., and they're deteriorating, so the council says, "Well, why are they deteriorating?" Well, the cleaners are power-washing them more often than expected, and it's making the stone deteriorate.
They're like, "Great, the solution is "stop them from power-washing." They asked why, and they're like, "Well, because the birds are pooing "all over the statues," and council's like, "Great, there's the problem." So they put up all this bird-proof netting, and you know, birds stopped pooing on the statues, but then you've got this bird-proof netting all over your statues, so it's really ugly. So they came back and they asked why.
"Well, why are the birds pooing all over the statues?" And it turns out, they're pooing all over the statues, 'cause they're going there to eat the spiders. So why are the spiders on the statues? Well, because all of the bugs are coming onto the statues, and so then there's more food for the spiders to eat. Well why are the bugs all over the statues? Because they light up the statues at night, at sunset, so people can take these great photos, like the statue's lit up against the sunset, and that is actually the core problem.
So the solution then was, "Let's not turn the lights on until it's completely dark." They tried that and amazing.
The birds went to sleep.
The lights came on.
The bugs came out, like everybody's happy.
So you've gotta keep drilling down into the why is this happening.
Like, get past the bird poo, and get to the core problem.
So there's a couple of frameworks we use to find insight, and we don't use every single one of these on every single startup that we work on.
All of our product managers are like very different backgrounds and different startups need different frameworks at different times, so these are some of the tools that we have in our toolkit, but we don't use all of 'em all the time.
So this one's one of my favourites.
Does anyone here know Jobs-To-Be-Done? A couple of you? Okay, so I love this one because, Okay, I'm gonna say this in a room full of product people, and I shouldn't.
I hate Personas.
I don't understand Personas, (chuckles) and everyone, every time I say that, they're like, "You just don't understand 'em," or, "You haven't seen 'em done properly." But I don't get, like, why Mary drives a Trivago and drinks lattes, like, what does that got to do with he clicking this button? I don't get it, and we can talk about that later, but I love Jobs-To-Be-Done, because it's a great way of really segmenting down into why is the customer using your product? And so the story goes, like McDonald's wanted to increase milkshake sales by 15%, so the product managers do the product manager thing, and they're like, "Let's change the features. "Let's, like, give new flavours," or "Let's change the cup size," and it didn't really have much affect on sales, because when you do products like that, it really doesn't. So they hired an agency who came in and said, "Well, what job is this milkshake doing in people's lives?" And they found there was two really clear, different jobs. So, lots of milkshakes were being sold in the morning, like 8:30 in the morning, and lots of them were being sold like three o'clock in the afternoon, so they're like, "Well, what job is this milkshake doing?" The ones that are sold in the morning were sold because people were commuting, and they were bored, and like they're driving with one hand, and they wanted something to do on a long commute, and a milkshake was great, because like, in America, milkshakes are thick shakes, and milkshakes are chocolate milk, but we're talking thick shakes here.
So a thick shake, or a milkshake, was doing the job of keeping them entertained during a long drive.
The ones in the afternoon, it was usually parents getting a treat for their after school, so the milkshake had different jobs for different people. So, as a product manager, you could then look at that and go, "Well, if I wanted to increase sales for "the people whose job is the commute," you'd like, in my mind, you'd make it healthy, 'cause like, buying milkshakes at 8:30 in the morning is disgusting, so you'd, like, make it healthy, and add chia seeds and oats, and you'd, like, make it interesting, and like give it a thick straw, so it lasts longer. And then the one for the afternoon, that's for the kids, you'd like make it hyper colour, or give away a toy or something.
So the milkshake had two really different jobs, depending on who the audience was, and also the time of day, so the context in which they were operating. So, customers are not buying specific products. They're actually hiring products for a specific job in their lives.
So a Job-To-Be-Done is expressed in terms of a functional job, so it's not just task analysis.
It's you're looking at the functional, but also the emotional and the social and all of the other aspects.
So, if you think like a Ferrari, someone's not buying a Ferrari because they wanna get from A to B, like the emotional context is like, they wanna show all the neighbours that they've made it, and they wanna like have everyone on the road look at 'em and go, "Like wow, look at that guy," 'cause it's always a guy. (some laughing)
(chuckles) Sorry if any Ferrari driving lady's here. So it's more that just the functional output there. We used Jobs-To-Be-Done with one of our startups called Aggie Global, and Aggie Global, some twins who lived in Fiji, and they're tryin' to solve the problem of farmers will grow their crop, and they're kind of, they're living on, they're not much money.
And so they're growing their crops, and they're taking them to the local markets to sell them, and then if they don't sell them, then they're taking them back home again, and there's a lot of, kind of, wasted time and energy, and they thought, "Well can we connect," you know, "the farmers with goods to be sold "with people who want the goods, "like this Ag Tech Marketplace?" But as we actually drilled down into the Jobs-To-Be-Done, we realised that one of the main buyers of this would be chefs at a hotel, but their job was, they actually wanna be creating innovative products using local produce, but they have no idea what comes in season when. And so this changed it from like a logistical startup, where you're kind of doing this marketplace, into much more of an educational product, because it's more about educating the chefs, like, "This is in season right now, "and in three weeks this is gonna be in season," and we could really help them plan out their menus in that way more so than just connecting people who want produce with people who have produce.
Another tool we use is a Customer Journey, so this kind of belongs in the room next door, because it's like a bit of a design artefact, but a Customer Journey is about mapping out how does a customer currently fulfil a job? So it could be like booking a haircut, or like I've gotta apply for the NDIS.
So you're looking at all of the things that happen to them at every stage and how they feel about it, and then you map out a perfect process and how people should be feeling, and kind of the gaps between one and two is where your product really lives, because frustrations are where products can come and help, so it's a visualisation of a process that someone goes through in order to accomplish a goal. I'm not gonna dive into this too deeply, because this is kind of like an hour long talk on its own, but we basically look at, you know, what's happening at each stage.
What are the artefacts? Where are the frustrations? Who are the supporting players, and how is somebody feeling about that? So we used Customer Journeys on an Ag tech product we had called PICMI.
So this is Jen.
She's the founder of PICMI, and she was a management consultant, living in New Zealand, and her dad had a kiwi farm, and he got run over by his own tractor, so she had to drop everything in her life, and go and keep the farm running while he was in hospital.
It happened to be kiwi harvesting season like as soon as she got there, and she realised that the way that her dad had been getting workers to come in and pick the kiwis was putting a sign out on the driveway that says, "We need workers," and just hoping somebody drove past, and stopped in and said, "I can help." And she realised that this is the way that like finding a short term worker in New Zealand happens. This is what everybody did.
She's a management consultant.
She's like, "There's gotta be a better way than this." So she came in saying, you know, "I'm gonna be an Ag Tech Marketplace, "connecting short-term workers with farmers." But as we went through the Customer Journey, we actually uncovered another really common problem that was happening with all of the farmers, that actually influenced the end product that we ended up building.
So when we went through the customer journey, we realised that it wasn't just sourcing these short-term workers that was a massive pain point, it was actually on-boarding each of these workers.
So farmers were spending about half a day tracking down paperwork, making sure the visa was valid, making sure everybody had done like the OHNS training, and all of this stuff, so it was taking half a day to on-board somebody properly for like a three day picking experience, and you'd be hiring 10 people.
So like, the admin on this is crazy, so that was actually what influenced the final product is, "Well, what if we had a way "that a worker could upload all of their documents? "We could check that the visa's valid.
"We could make them go through all of the OHNS things, "which were common from farm to farm." That all lives in the app, so a farmer just has to say like, "Yes, I'm gonna have this person," and the on-boarding is taken down to like one click. So that was really what drove the core product here, so it's not just about connecting these people. It's actually about taking away this massive pain point, because user frustration is where product should be living, like that is where you create the best products. So an Opportunity solution tree, this is a personal favourite of mine, and I'm fairly new to this one.
So Teresa Torres, from Product Talk, has done a great blog post.
I'll put a link on Twitter after this.
She's actually writing a book about it, because she's like, "This blog post barely scratches the surface "of what this thing is," but it's all about how you prioritise opportunities rather than looking at solutions.
So I went through the Opportunity solution tree, when I worked on JobMatcher.
So this was an HR tech solution that came in, and we were looking at how can we increase people with a disability in the workplace, because they're massively underemployed, and it's not because they're not gonna be good at the job. There's just like so many things in place that are stopping them from having successful employment, so as part of this process, we narrowed it down on neuro-diverse workers. So, neuro-diversity is people whose brains are wired a little bit differently, so autism spectrum, dyslexia, ADHD, and Tourette's.
So we were looking at, well, how do we actually increase kind of job-finding and being in a successful job for somebody who's neuro-diverse? So you know, we start off with our interviews. We interview 80 people, and I realised that the pathway to successful employment, if you've got a disability, is massive, and every single thing has to be right along this journey for you to have this good experience.
So the more people I interviewed, the more stuck I got.
There was one night I sat there with my head in my hands. I'm like, "This is an unsolvable problem.
"Nobody can solve this.
"Technology can't solve it." It's like, you need the work culture to be right. You need the job search to be good.
You need, like, the interview to be good.
Like, there's just so many part to it, that I was like, "I've gotta give up on this one.
"There's nothing I can do." Luckily I found Teresa Torres's blog post, and as part of that, she recommended this book called "Decisive" by Chip Heath and Dan.
Oh, Chip and Dan Heath.
There you go; they're related.
And they talk about the idea of multi-tracking. So multi-tracking is considering more than one idea at a time, and as a product manager, this was really counterintuitive, because I'd always been taught that you've gotta consider one idea at a time, and stay really focused on it, and get the metrics of that.
But they looked at companies who looked at ideas in isolation versus companies that looked at ideas at the same time, and they found that companies that considered quite a few things at one time made better product decisions, because you could actually look at each idea on it's own merits, and you got less attached to this one solution, which is what happens when your just diving on this one thing.
You're like, "Oh, I really like that idea," and you're less willing to change.
When you're looking at one idea in isolation, you come down to whether-or-not decisions, and whether-or-not decisions are where products go to die.
Because, you know, you look at the backlog, and it it comes out with this feature, and it's like, "Oh, Facebook integration, "should we do it or not?" And you've got this massive opportunity cost, and that is like, well, if it becomes a yes or no, and it's like, "Okay, yes." What could you be doing with your time that might actually be something that's better for the product? You don't look at that.
You just look at should we do it or not, so this is definitely something that we wanna be avoiding.
So, a product decision opportunity tree starts with your desired outcome, and this is written, like we saw so much about OKRs from at last here this morning.
This is written in the style of an OKR, so what do we want to actually happen? Then we can look at all of the different opportunities, and when we say opportunities, they're frustrations, so where are the frustrations that are happening to your users that would lead to this desired outcome? From there you can, you know, brainstorm a bunch of different solutions that are actually gonna address that particular frustration or opportunity, and then you can come up with experiments to really validate whether this is something that validates it or not.
So, with JobMatcher, we started off with the kind of outcome that we wanted, successful employment for someone who's on the autism spectrum.
Then we looked at all of the different frustrations that came up for our interviews, and like this was the part that had actually, kind of, atrophied me, but when you can break it down like this, it just was like, "Oh, actually, "now I can kinda come up with solutions." So it was like, "I did badly at the interview," and, "I got fired because I was too literal, "and I hate ping pong," and I'm like, "I hate ping pong too." But you could break it down into, well, what are potential solutions that address this particular frustration? So you know, if you did badly at the interview, because, you know, you're not making eye contact, there's solutions.
Maybe we could come to video interviews, or maybe we could give one on one coaching, or maybe we could do like online testing.
So when you're looking at these smaller, broken-down opportunities, it's much easier to find solutions, rather that going, "I've gotta solve this one thing." So we looked at, like, this guy who had had 437 rejections when he's looked for a job, and we thought, "Okay, well what are the potential solutions here, and we arrived on changing the language, because we know that somebody who's on the autism spectrum reads job ads really literally.
The guy that we had interviewed wanted to go for this job, but then it asked for a Bachelor of Comp Sci, and so he didn't apply for it, because he had a Bachelor of Engineering.
He had a Masters of Comp Sci, but the job ad didn't ask, "Do you have a Masters in Comp Sci?" It said Bachelors, so he literally didn't apply for this job, because he was like, "In my mind, well that takes me out." So we know that people on the autism spectrum, and interestingly, women read job ads quite similarly, so if there's a list of nine mandatory things, someone on the autism spectrum and women, if we've got like eight of 'em, we're like, "Oh," like, "I might not be good for that job," and like, dudes have like one thing, and they're like, "I'll be perfect." (many laughing) (Cheryl chuckles) Sorry, I feel like I'm really picking on men today. (laughs) Not all men. (chuckles) (audience laughing) So language matters.
This was kind of the core thing that we found, because job ads suck! Like we know that jobs are mostly bullshit, and you can try and find, try and read through it to find, like, the gems in there, but if you're autism spectrum, you take it all really literally.
So we're like, "Well, how do we solve that problem?" 'Cause that is something that tech can solve. So you know, we looked at that job ad, and we tried to divide it up.
Like there's so much inherent bias and bullshit in job ads, so we tried to kind of code like, "Which parts are bullshit? "Which parts are interesting? "Which parts does somebody need to know?" And we broke it down into plain text, so we put up the the lean experiment of, you know, can we rewrite six job ads to be plain text, and we put 'em up on all the job boards, and 80% of people, and interestingly enough, not just neuro-diverse people, everybody preferred the plain text version, because nobody likes job ads.
If I was to take this product kind of further than the first six month thing, I'd be like, "Well actually, "that's the product right there." Rewrite job ads for everybody, because when you write something to be inclusive, you're actually writing something better for everybody in the world.
So, if there's only one take-away, I want you to kind of that away.
Design for inclusivity.
So that can really help us in the product journey of well, where are we actually gonna build this product? So yeah, look it up.
I'll put a link on Twitter, but Teresa Torres, Opportunity solution trees.
I'm a big fan of them.
So language really matters.
Our founders all do this.
They do what we call the ice cream questions, so they'll go out and they'll validate, and often, when they try and validate, they're trying to validate that their point of view is correct, and so they really listen for answers that confirms their point of view.
And what we need to do is kind of just put all of that aside and be like, "Well, what is the actual problem that somebody's having?" So, I call them ice cream questions, because they'll go out and they'll be like, "Do you like ice cream?" And I'm like, "Sure, yeah, I like Ice cream." "Great, well what's your favourite, "chocolate, strawberry, or vanilla?" And I'm like, "Oh, chocolate." And then they come back like, "98% of our users love ice cream, "and like 70% of 'em like chocolate." But if they'd actually drilled down, like, I literally haven't eaten ice cream since 1993, and if you're building a product that's around, like, everybody loving chocolate ice cream, you've gone out to get validation, but you've actually not got validation at all. You've just really tried to confirm the things that you wanna hear.
So if there's any take aways, I'm gonna leave you guys with you know, talk to your users, and I don't just mean one off at the beginning of the product process.
There should be something that happens on a weekly basis, so you've gotta always just be out there understanding everything about your users.
Your insights should be actionable, so they're not just like anecdotes or a piece of data. You need an action attached to your insight. Validate everything with lean experiments.
Look for opportunities, so opportunities are frustrations, so really, like, listen out for those.
And drill down past the bird poo, so it's like you gotta keep askin' why to get to the core of the problem.
And there was one insight I was thinking on the walk here. Never, ever, ever go and create a corporate content portal, (some laughing) because nobody wants that thing.
Cool, thank you.
(audience applauding) (simple electronic samba beat music) (electronic snare scratching) (samba beat thumping) (synth chords music)
