(upbeat music) - Oh, thank you.
Thanks so much for that fabulous introduction, Megan. You might remember that before Cheryl's talk, there was a suggestion that around this time of the afternoon everyone gets to like this zombified state.
So, could everyone just jump out of your chairs. (audience laughing) Come on, and I'm not gonna make you do star jumps, but just have a little stretch, and shake your limbs and things like that, and just get ready to settle in for another 20 minutes. You all look fabulous today. (audience laughing)
Very, very nice.
So, I'm gonna be talking about pragmatism in product. In particular, cultivating a pragmatic mindset. So, I really believe that there's a lot you can tell about a person by what they choose to keep on their desk. This is my desk at Fathom, and you can sort of say it's generally pretty organised. There's like a small library of design, and product books, and a nice plant, and things like that. Cameron, who I work with, who's actually in the audience over there, his desk is even more minimal.
There's like two things on it.
And it's always super neat, because there's nothing there.
But one of the founders of Fathom has a much more chaotic desk, covered in paper and artworks from his children and things like that.
And he had this book on his desk for maybe six months. And I'm not a programmer (laughing).
I haven't coded in years.
So, I felt a little intimidated, but I had to crack it open because I am at heart a pragmatist.
So, this book was actually written in 1999 by Andrew Hunt and David Thomas, and it's quite revolutionary for its time I think. But you might all be thinking like, this was written two decades ago, and we're here to learn about like cutting edge stuff, like why are you telling us about this old book? So, what can it tell us about modern product development? Now, for me modern product development is like this, where you have this light proven idea and everything seems to be going okay, and then you end up in this sort of entangled web of your usability feedback doesn't match other feedback, and you're gotta like pivot around and make a lot of decisions.
And suddenly, your tech stack doesn't quite support what you wanna do, and it's all really overwhelming. So, what does it mean to be pragmatic? And like the textbook definition from Cambridge is that, to be pragmatic is solving problems in a way that's sensible, and it suits the current real conditions, rather than theoretical ones, and trying to just lean on fixed ideas and theories. So, if we're not pragmatic, we're at a danger of ending up with products like this.
Now, I don't know if this is more efficient than walking. I don't know what this is, to be honest.
(laughs) I found this, and I was like, what the heck? But I think even if this is better than just going for a jog, no one's gonna do this because this looks ridiculous.
And this is the other alternative, right? If we're not really pragmatic without product choices, we can end up with a bloated product that just says every possible bell and whistle, although I probably would buy this car.
So, we don't want to end up like that.
We wanna make genuinely good products that deliver value to people, right? So what makes that pragmatic product person? The very first right is that they're a big picture thinker. So, they take the immediate problem that they're looking at, and they put it in the larger context that really exists in. They're deeply realistic people, which can sometimes be annoying for others. And they're used to working with the chess pieces that are actually on the board, as opposed to the resources they just wish they had access to.
They're naturally inquisitive and curious people. And they constantly sort of asking questions and reevaluating and reassessing, are we doing things the right way? Are we doing things the best way? And really like critical thinkers.
This skills crafts people who are proud of their craft. So, whether it be design, development, product management, even testing, they deeply care about their craft and future skill development.
And lastly, they have this really scientific mindset. They want to test and learn.
And by doing that, they tend to make informed decisions, and really intelligent trade offs.
So, all these traits sound pretty good.
And can I get a quick show of hands, who has at least one of these things? Yeah, who has all of these things? Nobody, woo.
I thought there'll be a few of you, and I was just gonna invite you to leave.
(audience laughing) You don't need this talk, you're good to go. So, how can we cultivate this pragmatic product mindset? The very first step is to speak more than one language. Now, these tips come directly from this 20-year-old book. They need a little bit of reinterpretation and some ironing out of the edges, right.
So, in 1999, learn as many programming languages as your brain will hold was the message.
Like you should be learning a new language all the time, right? And again, straight from the book.
This is a fabulous quote, if you sort of reinterpret its context a little bit. "The limits of language influences how we think "about a problem." So, if I'm creating a specific language, I know all the limitations of it, and I'm likely to avoid things that I know won't quite gel with it.
So, in 2019, I think we can all agree, building product is 100%, undeniably team sport. There's lots of roles and lots of players, lots of chess pieces on board.
So, the new superpower isn't learning as many programming languages as you can, or as many design tools or as many frameworks, it's about learning how to work with your colleagues and teammates, and how to speak their language. So, how do you communicate better with your customers, and how do you speak the jargon of engineering? How do you work with product managers and get those intelligent trade offs? How do you understand what the hell the designers are doing and why they've made certain choices, and how to convince people in the business to follow your lead? Shared language and skill overlaps, within teams, just break down all the barriers and allow you to work together to build the same thing, rather than all these weird pockets of things that once you mesh them together don't actually deliver anything.
So, number two, be a catalyst.
Now, the scientific definition for a catalyst, is a substance that can be added to a reaction to increase the reaction rate without getting consumed or burned up in the process. So, essentially saying I can just like a secret ingredient, I can add to something that just makes it happen faster. So, if you can, imagine this scenario at work, you have this fantastic new idea for a product or feature, or it could be like a workflow enhancement, and you have this fantastic grasp on exactly what needs to be done.
Everything sort of come together perfectly. And for you, it's like, ugh, this is a slam dunk. This is like, my Hail Mary pass, right? Then you mention it to people in the office, and people don't quite get on board.
Everyone's a little cagey about it.
And people start to get nervous and start to guard their resources.
You can't have my depths because I don't trust you, right? So, I'm gonna tell a quick little European folk tale. I think this is from 1400s.
It's very old.
It's about three soldiers who are heading home from war. They've taken a really long journey.
They haven't eaten in months.
And they come across a little village, they're super excited because, maybe they'll give us a meal, maybe we'll have a place to stay.
Things are looking up.
They get to the village, they go door to door, and they ask, do you have any food to share? can we take shelter in your bond tonight? And people just turn them away one by one.
So, the soldiers an't sort of, as beaten down by that as you think.
They go back to the centre of the town, and they start to boil some water.
They put three stones they've collected from the river, (laughs) into the pot, and they start to just boil the stones, which sounds crazy.
The villagers come over and ask questions about it. "What's happening, and what is this? "What are you doing?" And the soldiers say, "You've got to wait a little bit longer, "it's not ready yet.
"But while we're waiting for this thing to boil, "and to come to fruition.
"Man, it would be really good "if we added some carrots, right?" So, one of the villagers hears this and she's like, "Man, I got some carrots." So, she runs back home to her carrot stash that she refused to share earlier.
She brings the carrots back.
And the soldiers' like, "Oh yeah, these carrots, "they're gonna make this stone soup so much better." So, the villagers keep asking questions.
"What's happening? "How long is it going to take?" Oh, not too much longer now.
But like some potatoes, that would be the best. So again, you can see where this is going.
Eventually, they just start throwing ingredients out there, some celery, some cabbage, some herbs.
And one-by-one, the villages are running back to their own private stash, and bringing stuff back and putting it in the soup. At the very end, the soldiers take the stones out of the soup, and they all get together and share maybe the first square meal that any of them have had in months. So, what do we learn from the soldiers? The villagers found it easier to get on board once they've already started something, even though it was something that didn't really make a little sense.
And by sharing a glimpse of a delicious meal, and sort of selling the dream a little bit, people sort of rallied together and started to contribute. It became really clear to the villagers, what they could bring to add to the pot.
So, when they were just saying, "Hey, we'd love some food, can you give us some food?" Everyone's like, "Man, I don't have any food." But they weren't really considering like if they brought some things together what they'd have. So, be a catalyst by helping the people around you see exciting possibilities of the future, and give them a very clear path to how they can contribute to that future.
So, number three, invest in your knowledge portfolio. Your knowledge and experience are your most important professional assets. But unfortunately, they're expiring assets. And this was probably more true in 1999, because if you learned a language, and you just sort of felt like you could rest on your laurels forever, and that language died, you'd really be in trouble. But it's still pretty relevant today, because tech is changing all the time.
You sort of got to be at least up with the curve. So, in order to invest in your knowledge portfolio, think about it as if you're making financial investments. So, you want to diversify.
The more different pockets of knowledge that you have, the more areas you can be useful in, the more adaptable you can be to new roles and new initiatives.
You wanna manage the risk of your knowledge portfolio as well.
So, you've got sort of this group of skills that, like especially in programming, you've got all these languages emerging all the time that are the new hotness, right? Everyone's like, "Gonna learn that, "that's gonna be so big next year." But if you try and learn too many of those things, and they don't eventuate, it can be really bad. So, it's better to also play some sure bets. And with that, you want to buy low and sell high. So, if you are one of those people who's fortunate enough to stumble on one of those trends that actually takes off, like a really early adopter of react or something like that, it can put you in a fantastic career position because when it blows up, you're one of the most established people in that space now. So, manage your knowledge investments in a similar way to how you'd manage your financial portfolios. And lastly, push for progress over perfection. This is probably the (laughs) main thing about being a pragmatic person, is just knowing when you can get things perfect and when you just can't, you're just gonna move forward. So, you can't design perfect software, we can all try, but the honest answer is that everybody has a different version of perfect.
And there's no single right way that we can deliver things that are a guaranteed smash success.
So, with that in mind, we have to plan to adapt and iterate almost permanently throughout the life of our product, that at no point, can we just sit still and say, okay, we're all good now, we've built something cool, and now we'll just earn money and never touch it again. Your customers' needs are always evolving, and your product needs to evolve with them in order to continue supporting them.
Otherwise they just end up leaving and going to find another product that solves their problems better.
So, in order to nurture this product mindset, we're speaking more than one language, we're all catalysts now.
We invest in our knowledge portfolio, and we're always pushing for progress over perfection. So, I've given you a lot of info.
I'm just gonna give you what I like to call knowledge nuggets, four of them, bite-sized knowledge nuggets.
And these are sort of product's mantras that will naturally help you in your day-to-day when you're communicating with people.
The things you can just drop in the conversation once you tell them what it means.
That'll sort of help everyone start to think this way. So, don't live with broken windows.
Does anyone know what broken window theory is? Show, yeah? 'Cos, but no (laughs).
Broken window theory is, it has its roots in criminology, basically means when there's a building, it has one broken window, and there's a whole street of other buildings, right? But that building is going to be the victim of the next broken window, and maybe some graffiti and maybe some litter and.
The idea is that, if you allow one small thing, one small issue to persist, it makes it okay for all these other bad things to happen to it as well.
So, you'll be working with an old file and someone's like, "Oh, this is an old file don't worry about it," and you just make a mess in there.
You don't know how many layers.
You just don't care 'cause no one else cares. So, don't live with your broken windows, fix things as you see them.
And if you do have to wrestling out the door, make sure you go back and make it right.
Horses not zebras.
So, (laughs) if you see hoof prints, think horses, not zebras.
It's far more likely it was a horse, especially in Australia.
The idea of this is to look for the most obvious thing first, and then you start looking left field for all these exotic answers to the left.
And this is a cool example.
I think it actually might have been at web directions last year, someone threw this into one of their presentations. I was so interested by this.
But they had this, this was a logic commerce store, can't remember the brand, but they had this idea that people from Brazil hated their products because no one had ever purchased anything from that store. No one in Brazil.
And they started making these changes and new marketing campaigns, things like that. And then they did some user research.
And they just found that Brazilian postcards wouldn't validate when people put them in the little postcard books.
So, people from Brazil literally couldn't order products. But they were looking for all these other reasons why people from Brazil weren't interested when actually they were interested the whole time. So, carve stones, but think cathedral.
And this is around, even when you're working on the smallest part of your product, making sure that you're always thinking about it in its big picture context.
So, where does this fit within the product? How does this fit within the experience? Because even though I'm focusing on just this button, I needed it to make sense all the way through. And when in doubt, ask the duck.
If there are any devs in here, they're probably know this already.
But rubber duck debugging, or just talking to a rubber duck, is sometimes as good as talking to a human when you're trying to solve a problem that you're stuck on. Basically, you literally tell a little rubber ducky on your desk what your problem is.
And you explain it to it in a way that the duck could understand.
So, one step at a time from the most basic parts to the most advanced part.
And by talking to the duck, you solve your own problem. And people might say that's stupid, until they realise that a lot of the time you use another human being in this way.
Has anyone ever done that? You walk over to someone, you tell them what your problem is, you explain it all, and then when they try to help you solve it, you're like, actually, no, I got this.
See you later.
You've, that's what you're doing.
You need a little plastic duck.
And that's all, thank you. (audience clapping)
(upbeat music)
