6 Steps to Build a Product People Love:

[2:37] When they are trying to grow and develop a successful product, what would you say are their major challenges?

There are so many and it really depends on the organization. I think one of the big ones is something you just mentioned which is that people really fetishize ideas. They think that great products come from great ideas. Like you are sitting around in the bathtub one day and you have a eureka moment and all of a sudden everything comes together and it's like Uber for left handed dentists.

I don't believe that that's necessarily where all products come from. We don't start with the idea, we start with the business goal and what we want to do. And then we move onto understanding the user needs.

If you think about most of what we do all day as product people, product managers, UX designers, UX researchers, people who make decisions about products. When you think about what we really do all day, what we are trying to do is we are trying to change user behavior in a way that benefits our business.

We are trying to convince users to do things that are in our best interests and I believe that we should be convincing them to do things that are in their best interest as well. Like we make ourselves rich by making our customers happy which is always my goal. I want to make people happy and make them into happy users of the product so that they are thrilled to give me their money to do more of what I'm doing.

I very much believe that we are trying to design things that change user behavior in positive ways for everybody involved. And that is different than, 'I have a cool idea for a product.'

I think we sort of need to shift our thinking a little bit about that because when what we are doing is looking at user behaviour, we are looking at problems that we want to solve or needs that we want to fulfill or goals that our users have that we want to help them achieve.

When we think about it that way, we might have many options, many things to try in order to help our customers reach their goals. There might be a lot of different ways that we could do that. As opposed to, 'I have an idea for a feature.' And then I go build it and it either works or it doesn't and maybe it was a good idea, maybe it was a bad idea, maybe it was good execution or bad execution.

But it's only one option. I've really closed off all of the interesting options for other things that I could possibly do in order to achieve the goal that I want to achieve.

[5:20] What would you say are the main characteristics of an ideal product team that focuses on company growth?

Lots of things. It's no one thing.

You said a couple of interesting things that I'd like to touch on. There are engineers absolutely who just want to code. And that is fine. They are solving hard problems in code and that is what they want to do and that is totally cool.

I have also found that there are lots of engineers who would love to contribute ideas and some of them are fantastic at making suggestions about how we might do things differently.

But often they lack the context to do that well because they are not told why we are doing anything. They are told go build this thing and then they go build it and they build it the best that they can. But 99% of the time, these are very smart people who have a lot of insight into a lot of things.

I think that having a diverse group of people working on a problem and diversity includes people in different areas of the organization. People coming at it from engineering perspective are going to have different kinds of ideas than people who come at it from a user research perspective or design or legal. Like if you have a lawyer in the room, you are going to get a different perspective than you would if you talked to an engineer. And that's great.

So I'm not on board with the engineers just want to code.

We are all making decisions constantly about the products that we are building. Engineers are making really important decisions all the time. Wouldn't it be better if they had more context and insight?

So we need to make sure that everybody on the team has a shared understanding of the goals of the product, the goals of the company, everybody should be able to tell you what the company's business model is. Everybody should know who the user is.

In the book, I have a lot of exercises that you can do with your team. Things like figuring out what your customer funnel looks like.

There is a thing called the User Map which is just 14 questions that you have to answer about your user to really make sure that you know exactly who it is that you are building for. And by you, I mean everybody on the team should know exactly who it is that you are building for.

I have something called the hypothesis tracker that gets input from everybody about what our predictions are for any particular thing that we have decided to build and why we predict that that's going to happen. And the specific metrics that will change.

When we all start to get involved in these kinds of exercises, we don't have to do everything all together but there are a few things that we should do as a team to make sure that everybody is rowing in the same direction.

[8:43] So what could teams do to avoid feature creep and quickly evaluate their product ideas?

A couple things there. That happens all the time. I deal with that constantly.

No. I used to say that there were times as a product manager I could've been replaced by a border collie that circled the engineering team and kept people away from them. Because my whole job was to keep the CEO out of the engineering space.

That said, I think that there are lots of ways that we can do this.

One is having that very clear business goal at the beginning of any sprint is critical and here is why. If your goal is to increase the percentage of free trial users who convert to paid users which is a perfectly reasonable business goal. That might be a thing, that's too low, we want to make that higher. We want to improve the conversion of free to paid.

That's a very specific business goal. Every time somebody comes to you and says, 'Why don't we add this cool feature?' You can say, 'Well that's a really interesting idea, what's that going to do for us? How is that going to help the business?'

First of all they have to answer that question and sometimes they can't even do that and they will say, 'Our competitor X has it.' And you say, 'That's really interesting. We don't know how it's working for them, why don't you figure out how that's going to improve our business specifically and let me know.'

Then if they come back and say, 'It's a great retention feature.' You can say, 'You are absolutely right, it is a great retention feature. Right now we are working on converting free trial users to paid but when we start working on retention, we will come back to that.'

The other thing that you can also do is say, what's the smallest possible thing.. what's the thing that you could do right now to figure out if we really do need to build that? What are some other options?

The nice thing about talking to them about what metric they think it will move or what the goal is for the particular feature that they are demanding is that once they say it's to improve retention, you can say there are these 17 other things that would also improve retention. Or we might come up with another thing that might improve retention right now. Why don't we figure out whether this is better than all of those that we thought were so important last week.

So lots of approaches there.

[11:41] What advice can you provide for companies trying to scale and explore the full potential of their product offer without falling into despair?

There is a huge difference between growing your product, growing your company, and growing your userbase.

Only one of those is something that you actually want to do. If you can grow your userbase without growing your products or growing your company, you will make a lot of money.

I don't have any employees, it's a consulting business but it's just me. If I could massively grow my customer base somehow without producing anymore product and without hiring anybody, that would be ideal, that would be perfect.

I think a lot of times people do confuse that and they think, we've got to pile on feature after feature after feature.

No, you do not. You have to find a super important problem and solve it. Or you have to find some goal that your user really wants to reach that they can't reach without you. And you need to help them reach it.

If you are looking to grow your user base, your problem may not be a product problem. Your problem may be that you aren't bringing in the right people or you aren't bringing in enough of the right people. Or maybe you need a sales team.

Or maybe you need a content marketing strategy. Or maybe you need a new feature. But adding new features and adding more people to your team doesn't necessarily get you what you actually want which is more paying customers.

This is a super weird thing that I've seen with some companies where I'll be like, 'Who are your users?' And they will tell me who their users are but they will say, 'Those aren't the users that we want.' 'Seems kind of mean to your users. Which users do you want?' They say, 'We want to be for everybody. Or we want to be for this much larger market over here.' 'Well great, does your product appeal to those folks?' 'It doesn't really but we want to get more of those in.' 'OK, well then you have to change the product or you have to change the market.' You either have to make a product that the people you want to acquire want to buy or you have to be happy with the users that you have with the product that you have. There are really no other options. I guess if you have the marketing budget of Apple, you can convince people that they want what you are selling. But most of us don't have that kind of marketing budget. And so it's really on us to either to change the users that we are bringing in or change the product to fit the people that we've got.

[14:50] So it's difficult to find a brilliant product that is successful. But what about when we do research and we know that idea won't work? What is the best time to give up on an idea?

Like we are done, it's time to give up.

That's so hard. If you read the Lean Start-up, Eric has a lot of suggestions about that. But you hear all these stories about companies that are like, we were running out of money and we were almost dead, and we thought we were going out of business. And then suddenly, something happened. And now we are all billionaires and we are doing this podcast from our yacht. But I'm not to be clear.

The problem is you hear a lot of survivor bias. Like you don't hear from all of the companies where they thought they were going out of business and they decided to push through anyway and then they went out of business.

That happens also.

I think what you need to do is you need to be very realistic and decide ahead of time what kind of evidence do I need either to move forward or to change?

I think you need to decide that before you run any experiments. So before you run any tests, before you build anything, you need to ask yourself what am I trying to learn with this thing that I'm building? What do I expect to happen? And what needs to happen for me to accept that this is working or this isn't working?

So I'm not on board with the engineers just want to code.

So you need to set that up ahead of time because it's very easy to run a test or experiment and go, 'Well we got some feedback and that's great. I don't know how to interpret these results. Are they good? Are they bad? Who can say.'

Well you should say but you should say ahead of time. You have to say before you actually run the experiment, how many emails do you need to get? How many people need to pay? How many people need to stick around? What is your algorithm for success look like?

Here is the thing, I've done a lot of user research and I will tell you one of the hardest things about user research is getting people to believe bad things that come out of it. But the research isn't about proving 100% guaranteed success or 100% guaranteed failure. It's about getting better input so that we can make better decisions and more informed decisions.

Yeah, here is the thing. Like I said, you are trying to derisk what you are doing but sometimes you just kind of go, I don't think this is working. And it's not working because we said if we got to here, we'd keep going and we didn't get anywhere near there. And so all signs point to it not working.

I will say this, I think that it's very important when you don't reach the success criteria that you set out ahead of time, it's very important for you to ask yourself why didn't I? What did I expect to happen and why did I expect that to happen? What did I get wrong?

Because that's how we learn.

People talk a lot about failure and how great failure is. Well failure is only great if you learn from failure. If you don't learn from failure, it's just painful and awful.

If you do learn from failure, it's still painful and awful but you've learned something and maybe you can avoid it.

It's never great. We avoid making the same mistake tomorrow. So that's arguably a positive.