(laid-back music) - Yeah, as Vegan mentioned, I started off in doing print design and I still have a pretty vivid memory of like one of the first projects I ever did. It was two weeks into my first job as a designer and it was to design this our company Christmas card I worked in the house for a finance company and back in the day when people sort of still sent out and spent a lot of money sending out all these like really fancy Christmas cards to clients and so yeah, I got handed this job and it was just, you know, open brief and the expectations were kind of really quite high because the previous years have been quite elaborate and a couple of them and one like print awards and those sorts of things.
And so I started working through some ideas and came up with this thing that was quite complex. Two pieces of paper that slotted together and would fold and you could tie it up onto a Christmas tree or it would sit on someone's desk and it had like two special inks and foils. And like I just went nuts and it was really hard.
I was using everything I just learned, you know, for three months before in my print design class in TAFE and finally I sort of sent it off to the printer, crossed my fingers that everything was okay and it was big, right? Like I think it would have been 1/2 six months salary, I think for myself at the time for this thing to go out. And so I remember kind of sitting there and the boxes arrived and we all like opened them with his great kind of feelings of anticipation and excitement.
And I remember all that really vividly but one of the kind of feelings I remember most is just the sheer sense of relief when it was done. So fast forward a few years.
Last year we launched a new product at Local Measure. It was the culmination of about six months or so of research and design and couple of iterations. It went through a little bit of a kind of beta phase, but the day that we launched, our COO came to me and sort of said, "you must be glad that's over, right?" And I think I laughed at her and I said, it's not over.
It's just the beginning.
So it kind of got me thinking of like this attitude now that in contrast to when we used to work in print or even working in agencies to some extent, you work on these projects in Done but now that a lot of us were working in product companies on digital products where we work through these things and nothing's ever really finished.
Endless iterations and iterations can close a lot of problems and so how is this like ambiguous nature of Done? How does it affect the way that we work? And how the kind of team feels while we're working? So I'm going to go through a few things that I've kind of observed today.
We are really good at starting things and I say we as in our team, but judging by the reaction, it's probably the same for all you guys as well. This whole idea of like the dreaded blank white page to me, I think that's a bit of a myth.
This is much harder.
My draughts folder has about 10 blogs ideas. I don't think I've ever published a blog.
(audience laughing) This talk started out as two paragraphs.
Basically, that story that I just told you and it took me like Kitting the submit button on the speaker proposals for actually to do it and I still did it in the last couple of weeks. And this is true, especially in a startup or in any company.
Like there's no shortage of ideas.
There's always a lot of things to do but not enough people or time to do it In.
Scott Belsky, he's now the CPO at Adobe.
He founded Behance.
He writes about this idea called the project plateau and he's talking about like when you get a new idea, the excitement and energy is really high and you put a lot of stuff in and you start to see progress and then as you start kind of executing, the excitement fails.
It starts to fade and you kind of hit this thing. He calls it the doldrums of projects management. And what often happens is you get bored and you just start on the next idea and then the next idea.
And so he talks in the sense of sort of new ideas and sort of entrepreneurs starting new companies and all those sorts of things But in product companies, it's like new ideas, they're just kind of new features.
So if you kind of look at this another way and have a look at kind of the focus and the effort that the team are putting in, you start off with a new feature and everyone's kind of really focused on it. And you get in there and then you get to a point where you're ready to finish and then things drop, but you don't realise that there's this kind of ongoing trail that everything that you ship has on your products.
And over time, this stuff just builds up and eventually, you get to this point where you start running out of room.
And here, you're either trying to like ship new features, searching for those quick wins all the time, or you start cutting corners at the beginning. If you then map this to customer value in an ideal world, every new thing that you do adds to the value that you're providing to your customers.
But in this world where everything kind of starts taking up the space and the maintenance and complexity starts adding to the product, you start to see this. With each new feature,
you're actually adding less value and then eventually, it starts to become this because the complexity just keeps adding and adding to it.
So there's a few things you can do.
The first thing is to just add more people. You know, if you're in a big company, where you have the luxury of being able to shift people around to different projects, then maybe that's a solution.
In a company like ours where we have to fight for like every single piece of money to get budget for people, it's just not really possible and also it's a temporary solution.
The other thing you can do is kill features, which gives you a little bit of breathing space, but killing features is really, really hard to do. In fact, those two things, hiring new people and killing all features are probably the two hardest things that you'll kind of ever do if you're working long term on a product.
So one good way is that the best thing to be done is to not start in the first place.
We've all heard this advice, right? And to have a bunch of articles saying, you know, product start strategies saying, "no, this one is like Jason Fried from Base Camp talks about all the time", if you like saying yes, then get better at saying no. It's really great advice and your future self will thank you if you get better and better at it but it's really hard when you're trying to shift into new market. So you've got like a big new customer and you kind of need that to survive.
So you can't say no to everything.
So more sustainable solution is back to this. You just put a little bit more effort into the end, try and reduce the long tail.
Think about how you can simplify the complexity of the things that you're adding so that you can build on top of those later. And that way you can still build some new stuff, but it gives you a little bit more room to keep going. So the other thing is you want to think about the transition from one piece of work to the next.
We work into experience.
I'm sure a lot of you all work into experience. The idea behind this is you need to take a chunk of work and you try and fit it in with this block of two weights. Then you grab another one and put it in the next block, but you're working on a couple of things.
So you know that looks like that.
Then you've got a few more people on the team so it ends up looking like that.
But in reality, the work is never really that neat. It's really hard to kind of shape stuff into these neat little blocks.
So what happens is you might take that piece of work and try and reduce it the scope so it fits neatly. We'll split this one and give it to someone else so that the two of them can work on to it together. But then there's some gaps.
So maybe we start to bring in the next project, give it to that person and let him just kind of finish off this little bit. But inevitably what happens is, this one ends up taking just as long as it should have in the first place.
This one ends up being a dependency of the other one, so it has to wait anyway.
Some P zero bug comes and that one just gets totally blown out and eventually, you end up with vicious mess of things where there's no start and end, and you're working on a whole bunch of different things at a time. Just kind of look at this another way.
This is I guess, kind of the rhythm or the shape of the piece of work where you just start off, you're kind of working out what to do and then it ramps up and you get sort of a little plateau and there's a little push towards the end and then it fades back down again.
If you think of this, maybe it's the kind of engineering team working on it. Product managers will start a little bit earlier, then it'll get design team involved.
And all of a sudden you've got this kind of mess of lines. You start bringing the next piece of work in. Product manager thinks they're finished now. So they'll start on the next thing.
Designer comes in again.
What often happens is because as the product manager started early, he starts bringing in engineers to start talking about that product.
So that gets sort of blending in and then over time, you end up with just this thing that just has no rhyme or reason to it.
The intensity is all really high and nothing kind of matches up and again, you're working on too many things at a time. So what should we do to fix it? First of all, you try to bring the beginnings and ends together.
This is really hard and it's really not that neat but at least try and match up the peaks and troughs so that everyone's energy is at the same place. Then in an ideal world, you don't start the next thing until you've finished the first thing.
This can be tough to do because people kind of think, people are too idle or it's too hard.
So often for us that ends up looking like something like this.
And then you have this kind of gap where you have sort of like a cool down period where you can take stock and here's where you might celebrate or just take a little break.
And this has been really important for us.
In reality, this is like hasn't worked for us this neatly. Most of the time we're in that chaotic state, but over the last couple of years, we're getting much better at like acknowledging that state and we always try and bring it back to this school down period so that we can at least finish and start something together again.
So I mentioned this gives us an opportunity for thinking about breaks and where we celebrate. I think that's one of the problems with this whole idea of working on something forever where nothing really finishes as it can get really hard to know like when do you stop? When can you say that something finished? We need to check things off the list.
So you need to really be careful about how you like get back to that feeling of closure that I still remember really vividly from 15 years ago. Don't do this.
So this was from a tweet just last week and judging by the thread, it happens a lot.
There's a lot of people kind of charming in. We actually did this, probably not to this extent but in the launch that I talked about at the beginning, on that kind of week when we shipped the product, we do team lunches on Fridays and we all announced and you know, we're all celebrating.
I looked over and there was like our customer success team sitting there frantically trying to onboard new clients under this new feature.
So it's kind of another thing is don't forget about the rest of the organisation. You might work as a product team or it could be even split into engineering or a little bit more like that but think about when you celebrate.
Don't forget the work that you're kind of shipping over the fence to your marketing team or your sales team or their CS team. I just kind of thought about this as I was putting together this talk, but this kind of framework seems like it might work. I haven't tried it, but it seems like it might work. It kind of matches the way that we've had successes in the last kind of six to 12 months.
So, take breaks based on output but celebrate outcome. So, output is about shipping and shipping is important. People work really hard to QA and test and ship and fix bugs and I think it's really important to acknowledge that, but you should be kind of taking breaks from that when you're finished with something or when you've like you're trying to engineer that, the cooldown period but then celebrate based on the outcomes.
And what we found with this is having that in the back of our mind, it means that you're thinking about the actual outcome of the work that you're doing.
An example of that, we've something that we actually just shipped. Last month is the week that it shipped.
We did it again, a couple of like probably a week, two week, a little bit of period.
And so the shipping really was just shipping a little bit of stuff and some onboarding and flicking on a few feature flags but we shipped that and we kind of acknowledged the engineers and our head of product actually went around and left key caps on everyone's bench with a little note saying, "well done, take a break." But then we're starting to celebrate the outcome. So we had kind of a goal for adoption for that and we have a Slack channel that is posting like all the activations that come in and the whole company is actually in on that. And as like a new client comes in and we sort of have a global presence.
So we'll have a new client in Dubai that signs on and there'll be a whole bunch of reactions and gifts and stuff like congratulating the CS member who kind of looks after that client.
And it's a really good way to one, keep that feature and that's piece of work in top of mind. So we're not just shipping and moving straight onto the next thing.
And also it makes us think about kind of what the actual goals are of the features that we're trying to do.
So just to kind of give you some summaries, certain takeaways, don't be so quick to start the new and shiny. Understand that sort of every new thing has it's long running goals especially if you're not careful about how to do it. Put a bit of extra effort into the end of a project. Really work towards kind of wrapping it up nicely so that you're trying to reduce that ongoing cost. I feel like this is where it's web direction. So I need to mention design systems, but I feel like this is one of the things that people like, where even I feel like adds the value of design system is because it's trying to reduce complexity. So even if you at the end of a project, kind of do what you can to push that back so you can reuse what you've done and it makes everything ship each feature and each thing that you push should be making your future life easier, not harder. Don't try and make things too neat.
So don't play Sprint Tetris.
Be okay with like having a couple of little gaps there because shit always goes wrong.
Pay attention to the transitions.
Learn to identify that chaos and work to kind of bring it back to alignment and to calm. And then being intentional about breaks and celebrations. Take break space and output.
Celebrate outcomes and don't forget about the rest of your organisation. Thank you.
(audience clapping) (laid-back music)
