Show Notes
Hello, and welcome to the bottom up skills podcast. We are back again, and we are setting ourselves into a world of design thinking. And as part of our design thinking series today, we're going to be asking how do we define the most important the primary feature? Of your new product. And the funny thing about this is you might think to yourself that that is often a very obvious choice.
And what actually turns out is that it is it's been really hard. Thing, because you know, you've done heaps of research. You've got a lot of data there's maybe competing ideas for, what's going to be the killer app in this new product or service. So what we're going to do together today is I'm going to take you on a journey on how you might just pick one.
And, um, we'll really kind of use some different models and different techniques to learn how to make a better feature choice. And the last thing I'll do with you is just share with you my thoughts, why this it's so damn important, because if you don't do it, the consequences. They can actually be pretty dire.
So particularly if you're building a large scale product, that's going to serve a lot of users. So let's take a little journey into choosing the primary feature. And what we mean is the killer app. What is the thing that is going to make this product or service unique? What is its point of difference?
Where inherently is the core value? Because let's be honest. I log in screen. Yes. It's an important feature. It's maybe even. An important user story made up of some different tasks and elements, but we all know that that's a pretty standardized feature, so we need to get, so the thing that is most important, because when you choose that, and this is really, really important, it should be the first thing that you start building.
Yeah. So you don't start with the login. You don't start with the admin tools, you start with your primary feature and I'll explain what happens when you don't do that a bit later on. So. How do we choose? How do we know what the primary feature is? Now? This is particularly powerful when you're building a first generation product, something brand new, because if you've already got a product, chances are you've started to really work out, uh, where users, uh, value your product or service, where they perceive, uh, the most important parts.
But these questions you can ask of an existing product, but they are on their own. They're super special when you're starting from scratch on a gen one product. And, um, I'm going to give you four questions that you can ask of yourself and of your team. And I'm going to give you some models, uh, that kind of take it next level if you want to do so.
And, um, I want to start with, uh, I'm going to give you the full questions and then we're going to break them down. Okay. So you want to know the primary feature? Well, if you've been tuning into any of these podcasts or if you've done any of the master classes on bottom up.io, you know, we always start with the user that is at the heart of design thinking.
It's at the heart of our bottom up methodology. And we ask ourselves this question, Of all the features that are on our list of all the possibilities, which feature creates the most value for the user. The second one you could ask, which feature creates the most value for the business. Third, which high value feature is the simplest to build, which I value feature is the cheapest to build.
Now for the top students of this podcast, you'll notice that I am using what is essentially an architecture of desirability, feasibility, um, and viability. Yeah. But I want to get into each of these simple questions. And by the way, you can get all of these in a PDF form. Just head over to bottom up.io grabbed the mass class.
It's all free, but let's talk about each of these on their own, which feature creates the most value for the user. Now, if you, as a team are having trouble answering that question. Whilst that's a bit of a concern. Don't worry. Cause you need to go back and test more with your prototypes that we talked about.
In the previous episode, you need to go back to your users because your work on user insights. Through interviews through surveys through actually building a prototype should clearly resolve which feature creates the most value for users. Now you could be in a situation where you have two features. I'm actually working on a product right now.
Um, and we've got two features that are. Really unique. And we're very attached to one of these features in particular, but there's a companion feature, uh, which is all around education, which might be the dark horse. Now, when you have a situation like that, where there's, you know, two features that rise above all the other features or user stories that you have, that's a luxury problem.
And, uh, you can, um, You can start with either of those. But I think my most important advice here is if you're not clearly to discuss as a team objectively based on data and insights from quantum qual research, if you can't articulate and agree, which value creates the most value for the user, I would pause right now and I would actually go back a step and test again.
So that's first thing you can do to work out which feature matters most. The other one you can do is work out, which one creates the most value for the business. Now, the only caution I would say with this is don't go building features for the business and neglect the user. But what I like about this question is it often helps.
Create a balance in the features or user stories that you build so that you are creating value, um, that strikes. A balance, a balance between the business requirements and the user needs. And this is often a very subtle, very sophisticated thing that happens on a bigger, more enterprise, um, products, but it's a very, very important balance to find.
So that one is which feature creates the most value for the business. Now the last two, which high value feature is simplest to build, and which is cheapest to build are very important. Now I know that we're doing a deep dive on design thinking, but I want to run in parallel some insights here around.
Agile development and the implications, these moments where design thinking and agile work together. Cause they're very cool. The reason that these questions are really important is we can sometimes paralyze ourselves by trying to build something incredibly complex, something that. In modern, uh, language has maybe a dozen web services or micro services, uh, that has a hybrid cloud environment.
You know, people start doing things like that, and that is complex and we know complexity equals time. So when you're building a brand new product, there is nothing more important than going. Fast because you need my mentum and you want to ship product to customers as quick as possible because you want their feedback.
And that's really at the heart of design thinking. Now another important one, and this will probably be working for a lot of you folks that are in startups, which is which high value features the cheapest to build now. This can be very important. Let's say you're a startup and you've got a funding horizon.
Maybe there are features that are really how awful in the hands of uses, but they require a significant investment and perhaps you can solve some smaller problems. Um, important problems, but you can solve those demonstrate value for the user, which creates value for investors. And you can do a really good raise, um, in your seed rounds, uh, maybe even in your angel rounds so that you can ramp up to go after a bigger prize down the track, these four questions.
I mean, if you're stretched for time, Just use these full, simple, powerful questions. And if you struggle to. Answer them. If you don't know what is cheaper to build, what is fastest to build, if you don't know what's creating value for users and businesses in terms of what you plan to do inside of your product, then pause right here, go back.
Reexamined. What you have. What you've learned from tech farm, your business analyst from your UX folks, go back and check because before you build anything, you should be pretty clear on what the answers are to these questions. Now, some advice, if you're thinking about this and sounds great. W w how do I do it?
Where do I start? I would jump into creating user stories in JIRA, um, and. To use that as a way of prioritizing your feature list or what we would call a backlog of issues or user stories or user points. Yeah. This would be the most simplest step to take right now. So, you know what you want to build, get it into JIRA, hopefully, uh, or another product from Atlassian, which is confluence built your shed.
Yeah. Knowledge, insight, and documentation of all the thinking behind the product from a business tech UX perspective. But the reason why juror is really important is it will help you prioritize your backlog and picking your primary feature is the art of a prioritization. Now, if you are inclined to go a little deeper, there is a methodology.
Uh, it's actually basically an equation it's called the rice score. R I C E. Now the R stands for stands for reach I for impact C for confidence E for effort. So what this model does is it asks you to rate a particular feature on how many users it's going to reach, what kind of impact we think that might have.
How confident are you of its success. And you put that yeah. Over effort. So this calculation will give you a rice score. So you might not want to do this for user stories. Cause there's a lot of those and the writ too small, but definitely themes may be maybe your epics. Um, but this would be a more quantitative way of, of working it out.
So. If the earlier four questions are not enough, maybe you guys need to go next level. I would go to this rice score. It's a very powerful way of rating features within a product. Now I said earlier that. You shouldn't really underestimate this, this choice. And I really want to take a, uh, a minute to explain why this matters so much choosing your primary feature is what I don't want you to do when you start building your product is starting with the easy stuff or starting with the standardized stuff.
Meaning like a logging, uh, an account page, an onboarding page. Don't start with the easiest stuff, because if you do, uh, that sort of prioritization, you will find yourself most likely in a huge trap. You will have spent time building all sorts of very standardized repeatable stuff, and you will have neglected the core feature.
And what you'll often find is things like, Oh, it took us a week long to get the AWS account set up because there was issues with that. Oh, a get hub wasn't working properly. Oh, the UX person's on here holidays. And then all of a sudden, yeah. Could be two thirds through your development phase and you haven't really tackled the core product.
Is this an invaluable lesson. This is quite a painful lesson that I've learnt over time. And I would strongly encourage you to make choosing the primary feature. Not only the most important thing you do when you have the team together and you're ready to start a sprint, but that you then once choosing, what is your primary feature?
What's the killer app. What makes this whole thing so different to everything else in the world is that is what you dedicate the that's part of design and development too. Do not fall for the trap of doing a very nice login page, do not do that far. First, do that last start your design and development with the primary feature.
Cause you might uncover all sorts of unexpected complications and you would much rather have a lot of time for that and have a quick and dirty bootstrapped login page because your users in the end will trade that off because the feature. The lights and satisfies and then helps them get a job done.
And that is what we're really about when we're building product. So do you have that defining your primary product feature? It's a big one. It's a huge one. I hope you've got a little bit of advice and inspiration on how you can make sure you start on the most important things first. If you'd like to download the entire design thinking master class, you can do so@bottomup.io, I've really enjoyed sharing with you.
This journey of design thinking. There are plenty, more episodes to come. So thanks once again for joining us on the bottom up skills podcast, that's a wrap.