7 steps to build the right product

So what methodologies and frameworks should you use to get started? It can be very confusing, for good reason, when it comes to methodologies, frameworks and techniques. What is the difference between Design Thinking and Design Sprints? Should we look at Lean Startup or Agile?

If you start googling you’ll quickly find a lot of different graphs showing you how they fit together or which one is the best. Honestly, having worked with a lot of them I think the overlap is so big that it doesn’t really matter. Sure Agile focus on the development and Design Thinking starts with more of the framing, but building a product you probably want to do a bit of it all.

Every agency and comapany say they have a unique framework, but I still haven’t seen one that isn’t closely related to the next one (in some instances they just draw the graph differently).

Because of this I will focus on 7 steps that should be done no matter what you want to call your process.

The success of any product or service depends on if it fulfills the intended users needs. If they don’t see any added value from a time or business perspective they will move on. Because of this we start with the users.

Your team need a clear alignment and shared understanding of the efforts and pain points of your users. If you, as a team, don’t understand what you are trying to solve and for whom, you should take a step back and figure that out first.

The more you understand your users, the easier it will be to make decisions about what you should and shouldn’t include in your product. To understand their biggest pains and gains, and when do they occur, will also make it easier to focus your product and enhance the experiences down the line.

So how? There are plenty of tools you could use for design research (see image below). I tend do lean on user interviews, competitive analysis, and benchmark studies, but find the one that fits you the best. If you feel you need better understanding of user-research, a good place to start is this Medium article by UX planet and some of Nielsen Norman Group’s work.

When you have enough understanding of the users you can build personas or archetypes and start working out user-journeys.

To actually build a product, is all about knowing which 99% of your ideas to initially ignore and which 1% to focus on. This is where the MVP (minimum viable product) comes in to the picture.

Building an MVP means that you should build the bare minimum functionality needed to fulfill the user need you are trying to solve, at any given moment (no extra functionalities). 

That being said, this doesn’t mean it should only have all the bare minimum features (functions), it needs to be useful and add value.

Last year I worked with a company that was completely sold on the lean start-up idea. They were trying to test ideas by quickly building prototypes and if they didn't work they tried something else. The idea of doing this sounds great, but they completely ignores usability. You can't test the viability of a product if no-one understands how to use it.

I have written a separate article about MVPs to explain it a bit further.

To create a great product you need a great team. No shit Sherlock. So let's be more specific. A team with a diverse background preform better than a bunch of people that think the same way.

Most large organizations I've helped usually have their team ready to go. It's a bunch of developers, a BA and a PM. Cross-disciplinary competences is more important than experts. Of course you need people that can actually do the tasks required for the project, but diversity leads to a more creative and problem solving environment. On top of that if your organization is trying to go through a digital transformation,  create a lighthouse-project, you need to spend time on compiling the best possible team. In those cases it needs to be cross-silo and cross organizational. Anything to help buy-in across the organization.

Here the startups I've worked with seem to have exactly the same issue. They only hire people that have done the same thing before. Yes, core knowledge is important, but you miss a large opportunity to create a diverse team that won't all think and act exactly the same.

When your team is set, they need to align on a shared understanding of the effort, users and pain points (see 1. Understand your users). Everybody needs to pull in the same direction.

If you keep working on your product until it’s ‘perfect’ you might very well end up wasting months (or even years) on something no-one actually wants. By realizing it early you continuously make it better based on actual insights.

As mentioned in the first section there's multiple ways you can do user testing. To learn more about user-testing check Nielsen Norman Group's resources.

 Put on the product manager hat. Define goals to hit continuously and keep increasing them. It should be KPI:s (key performance indicators) that will take your product to the next level. Think of it as if your product had more _____ the company would be doing better. Eg. More messages sent on Whatsapp would mean they’re doing better.

Of course the KPI:s might change (probably will) along the way and that’s completely normal, just make sure that you keep measuring.

Focus your design on the ideas that will help you reach your goals the fastest. Don’t just randomly add new functionalities and ideas you think will be good, but use your users. After all they are the ones you are building for. If you actually talk to them in user interviews and testing you will learn a lot. On top of that you can also get feedback from reviews and data, analyzing their use of the product.

Your time should be spent on improving the areas that affect this main KPI:s. And to be clear, this doesn’t mean that you should only focus on functionalities. It needs to be intuitive and delightful. If the users don’t understand or enjoy the product they will find something better.

Building products this way means you’re never done, you just continuously improve your product. Keep experimenting with the product’s design. Try to simplify it, remove obstacles, add new ideas etc. If something doesn’t work, move on and try something new.

Writing this made me think of one of my favorite podcasts, How I Built This. In the episode about Chicken Salad Chick, the founder explains how she just kept iterating on her MVP (her chicken recipe) over and over again until she saw her user light up when they had it. What I'm trying to say with this is, it doesn't matter what product you are building you will always iterate on it.

This is why everybody are talking about Agile (and all employees at large organizations are scared of it). To explain Agile methodology would be a whole other article, but basically you continuously iterate along the development of your product.