Common Mistakes

[00:00:00]
>> So there's kind of three common mistakes that I often come across when I see people kind of prioritizing their workloads around features and minimal viable products and all that kind of stuff. And I just wanted to flag up for people really. First is rushed The pressure to deliver is often so high that people jumped straight into prototyping without doing any kind of upfront user research and on the course that we did on user research and testing, I shared some ways that you can actually do a discovery phase pretty quickly and pretty well.

[00:00:39]
I So, I'm not saying we always need long drawn out discovery phases with endless user interviews and diary studies and all these kinds of convoluted stuff. But just taking a pause for a minute and establishing some of the basics in terms of what users need, who the user groups are, those kinds of things.

[00:01:01]
You can't just jump straight into Figma every time when you're kicking off a new feature, or working on an MVP. The other big problem is post launch iteration not happening. I've really already said that, so I don't need to say a huge amount more there. But after a feature is delivered, nobody's checking back to ensure that it's performing.

[00:01:25]
Whose job is that? There's a question for you. I honestly don't know, right? Whose job is that? If you've got a product owner, then fair enough. But oftentimes, there isn't a product owner, which is a whole problem in its own right, right? So if I'm working in a product design role, I would take that on as one of my responsibilities.

[00:01:53]
Because I feel that, that post launch optimization and iteration is so fundamental to the success of a product and the design of a product, but I have to keep flagging it. And then finally, a lack of holistic thinking. This can be a problem with Agile, right? Don't get me wrong, I wouldn't dare criticize Agile, because I value my life.

[00:02:21]
But, Agile is, I dare to say not perfect in every scenario. And it is a model that has been born out of developers and how developers work. And one of the things when it comes to product design is it's very important to think holistically and to kind of see things as a whole.

[00:02:43]
And when you work in sprints, which are focused on an individual feature or something like that, you don't have that sense of kind of big picture, how all of these bits fit together. And so that's dangerous. And I just wanted to flag that. In terms of solutions to it, you can do things like a Sprint Zero upfront where the designer gets some time to do that kind of stuff.

[00:03:13]
I tend to say there is value to that. But there is another solution that I'm gonna propose in a minute, but was there a question, did I see Mark?
>> Yeah, there's a little bit of discussion going on-
>> I'm scared now, please don't be horrible to me.

[00:03:33]
I didn't mean to criticize Agile.
>> No, I feel like product requests should be handled mostly by the product owner, not the developers, but also that depends on how big the company is.
>> Yeah, this is the trouble with doing a course like this. It's hugely different talking about an enterprise customer compared to something that's the size of front end masters or maybe even smaller.

[00:03:59]
Obviously, you have to work in different ways in different situations. If you've got product owners, then the product owner should own the backlog of features, etc., using all the same principles that we've talked about, but the ownership should probably lie on them. It certainly shouldn't lie on the developers, in my opinion.

[00:04:20]
Because, that's not your job, yes?
>> But on the other end, somebody said that the highest functioning teams that they've been on the developers did share some of the product ownership.
>> Yeah, there's a difference between contributing to that process and owning that process, right? So I'm a great believer that product should have an owner, right?

[00:04:53]
A person ultimately makes the decision. But if that owner is a good owner, right? They should be working incredibly collaboratively with their entire team to define the order of which things are done with. So for example, I was saying well, okay, the pointing of features. One of the criteria should be the time and effort involved.

[00:05:16]
Well, that's down to the developer primarily to tell you what the time and effort is gonna be involved in it. And so, yeah, it should be a collaborative process, but that doesn't mean you shouldn't have someone that ultimately owns it. Because if everything is done in this kind of group, think, mind kind of approach, things slip through the gap.

[00:05:41]
Especially around things like post-launch iteration and stuff like that. So yeah, there's a balance there. And it also, it depends on the culture of the individual organization and the team that makes it up. Yeah, go for it.
>> So Valve is a 350 person company, a multi-billion dollar game platform that also makes their own hardware and games and there are no PMs or managers there.

[00:06:09]
Leads are volunteer roles that focus on organization and deal with the press and lead baton is passed every few years. But they do have leads.
>> Yeah.
>> It's just they're a little bit more fluid.
>> Valve is an really interesting case study. I love Valve and the way that they operate.

[00:06:30]
Which is this like for example, I don't know whether it's like anymore, but for a long time, projects with the survival of the fittest. If you had an idea for a product, you had to persuade the team to come and work with you on that product, right? Brilliant, really interesting.

[00:06:47]
So they do some really innovative stuff there. And it's great to look at them and go, that's interesting, but you can't take that and suddenly plaster that on another organization, it just doesn't work. Every organization has a deep rooted culture and ways of working, ways of thinking, ways of behaving.

[00:07:10]
And something like Valve needs to be built from the ground up from the very beginning. So it is really interesting story, but I don't think it's one that you can necessarily learn huge amounts from personally.
>> Well, I have a question. So no holistic thinking is a mistake.

[00:07:27]
How do you prevent holistic overthinking? Especially, if you have a group where you try to get contribution from stakeholders, developers, design team, and sometimes it's just becomes the war ducks.
>> Yeah.
>> Especially for legacy systems.
>> Yeah, so I would encourage you to check out my course on user research and testing, because I use testing and research to cut through all of that, right?

[00:08:03]
So, the problem only comes it's fine having lots of stakeholders, all expressing opinions, right? That's all right, okay? The problem only comes when a there's nobody to make the final decision over it. And b, there becomes points of conflict and disagreement between the stakeholders, both of which pretty much always happen, right?

[00:08:28]
Those are so common, it's ridiculous. So, if we don't have someone that's making the final decision and who is informed to make that final decision. Then, well, let's find out. Let's get hard evidence to support this. So whenever there's any kind of disagreement, I turn to testing, right?

[00:08:49]
Let's ask users. Let's find out. And that course is all about lightweight ways of basically doing that. And we will touch more on some of that latest, if I ever get moving forward, cuz we're all getting so into the questions, which is great. So let's push on. So yeah, we've got these three problems, right?

[00:09:09]
And the last one in particular, this holistic thinking is a big issue, because often we don't have time to do that, yet it's incredibly valuable.