‍Hello! Business is all about attracting as many customers as possible, but as we said in one of our previous episodes, . Some may negatively evaluate our product, waste our time, or use it in a way that may harm themselves or others.: Hello, in today's episode we continue the topic of patient experience. So if this is something that interests you, I invite you to listen to this episode. And our hospitality will be , which has been working for many years . I invite you.

We are designers. We run our own agency and share our experience and practical knowledge, which comes from the projects we implement.

‍

‍

Too many ideas at once

‍

Ilona: And today we're tackling another problem that we encounter daily in our projects and that our clients come to us with.

Namely, they have a lot of ideas for functionalities to include in the product. And they don't quite know which ones genuinely bring value and which ones customers will be willing to pay for.

‍

Radek: Yes, and this uncertainty stems from the fact that we have different people on the team who might view our product and its development a little differently.

A person who is a product owner will think about it differently. A designer will think about functionalities differently. And someone who is the originator of the entire venture will think about it differently still.

When you gather all these ideas into one basket, it turns out to be a really large collection. And it's very difficult to choose the key functionalities for which... as she said earlier

‍

Ilona... for which the client will pay.

‍

‍

What will the client pay for?

‍

Ilona: And this situation will apply to products that are just starting out (meaning they're not yet on the market and are currently being developed), as well as those that are already on the market and looking to grow.

The problem remains the same — what to put on the roadmap? What to include in the plan as the next functionality so that the product brings greater value to users?

‍

Radek: And there are two levels to this problem.

The first level is when we internally within the team need to create a shortlist of functionalities, which is still a hypothesis, but a concrete one.

The next level concerns the user. This is a list of functionalities that the user will identify as interesting to them and potentially worth paying for.

‍

Ilona: And at this point, we come in — the user experience designers.

‍

Radek: We won't come ourselves, you have to come to us…

‍

‍

The buy a feature exercise

‍

Ilona: OK… so when you come to us and ask for our help, we'll pull out an exercise from our bag of tools called buy a feature, which loosely translates to "buy yourself a feature."

‍

Radek: First and foremost, this is an exercise that works perfectly in these two cases when prioritizing that long list of functionalities that we managed to create as a team.

It will also be useful in discussions with the user to finally narrow down this list to its ultimate form.

But what are the mechanics of such a study like?

Before we explain the basic form of this study, it's worth mentioning that it is highly adaptable. It can be conducted individually with one person, or as a group session.

In this core, buy a feature is primarily a simulation of the purchasing decision-making process, whether in a group or individually.

And now, let's imagine we have a list of, for example, 30 functionalities. Each of these functionalities has its own price...

‍

Ilona: And the price varies. One feature costs 1 PLN, another 10 PLN, and another 15 PLN.

‍

Radek: Yes, but if we were to sum up these amounts, it would come out to, for example, 100 PLN. And the person participating in the study has 60 PLN in their wallet.

‍

Ilona: Which means they have a limited budget.

‍

Radek: Yes, meaning they won't buy all functionalities. They have to decide for themselves which of these functionalities to buy.

‍

‍

Quantitative and qualitative knowledge

‍

Ilona: On the one hand, we limit the budget, and within that limited budget, our respondent chooses what is most important.

As moderators of such an exercise, we sit next to our respondent, see what they choose, and have the opportunity to ask them about their reasons. We can ask them why. This gives us a great combination of quantitative and qualitative knowledge.

‍

Radek: Yes, and with such user research, for example, in a 1:1 session... Let's say we conducted 6 interviews with a buy a feature study... Then we can quantitatively calculate how much was spent on a given functionality in that group.

Qualitatively, we can also gather feedback from customers on why they made a particular decision. Why did they spend their money on these functionalities and not others? Which ones were a difficult choice for them? Where did they hesitate?

This is very important qualitative knowledge, which is then used, for example, as a sales argument.

Here we touch upon a great relationship between design, which brings some insight, and marketing and sales, which can use these arguments in communication to sell a given product.

This is an absolutely crucial aspect.

However, when it comes to an exercise during the phase where we're within the team, discussing functionalities that each of us brings to the table, it's a great opportunity to discuss each one of them.

It's an opportunity to truly consider together the various aspects associated with introducing a particular functionality.

Because it's not just part of our strategy, but also, for example, our budget, which the technology required to develop something might consume.

And of course, there's the user aspect itself. To what extent do we believe it will genuinely bring value to our client.

So this is also the moment where we, as a team, can discuss and think about it together. Usually, in our daily work, we don't have the time to tackle this and truly work through the topic step by step.

‍

‍

When we don't know what to test

‍

Ilona: Radek, I have a situation for you. Let's say I represent a product that's been on the market for some time, perhaps two, three, or four years. We have a huge backlog of features, and we want to test some of them with users, but we don't actually know which ones. What should we do in such a situation?

‍

Radek: I understand you're a client who visited our website www.designzima.com and contacted us through our form.

I would definitely want to start by collecting from you a list of all the feature ideas you have. And I would investigate the basis on which that list was created, because I wouldn't want us to work on things that just appeared out of nowhere.

I'd like these to be things that consider user-suggested functionalities. This applies if we have such suggestions, or if we've gathered this information from research we've conducted.

And I'd like these to be ideas that are inspired by our competitors. We see that the competition has introduced something, and we suspect it could work really well in our product. Or, for example, we might have some enhancements based on what we've already observed from competitors.

And functionalities that were developed based on our strategy that we aim to pursue. This is also extremely important. As a company, we have ambitions and aspirations; we want to achieve certain goals. And these functionalities must also be consistent with that direction.

‍

‍

Must have, should have & nice to have

‍

Radek: Bearing in mind that our goal is to arrive at a shortlist that we can then test with users, we first need to conduct an internal 'buy a feature' exercise.

To do this, we need to assign a value to each of these features. And we assign this value through an exercise called must-have, should-have, and nice-to-have.

The point is to group our features by, for example, cost, difficulty, or how necessary we think something is for the user.

And for example, must-haves are features that are inexpensive, which we consider the core of a given product or part of a product. And here, we are almost certain that they should be included.

Should-haves are features we're not entirely sure about. We don't quite feel... It seems to us that they should be included, but we're not as convinced as with must-haves.

Nice-to-haves are total bells and whistles. These are usually expensive things that don't build core value.

Once we have all the features that we previously listed in these three areas, we can assume that all features categorized as must-haves are worth one point.

Should-haves will have two, and nice-to-haves three.

This means that during the study, as a user, if I want to buy a feature that has been designated as a must-have, I will have to spend 1 point. To buy something from nice to have, I will have to spend 3 points, which is more.

This is very good because for the exercise itself, we can assign specific amounts. For example, a must-have feature costs 10 PLN, a should-have feature costs 60 PLN, and the user's budget is 120 PLN.

But you came to me, Ilona, as a client. So, after this prioritization, I would probably suggest an exercise with your entire team.

I would take 4-5 people who are primarily responsible for the creation or development of this product and conduct a group session with them.

I'd like you to collectively decide what your shortlist of functionalities will look like.

This is a great opportunity for you to have a lively, responsible, moderated discussion about what will make it onto this shortlist.

‍

‍

Tallying points

‍

Ilona: Alright. We've had this discussion, but the question still remains: what should we test?

Radek: We prepare a summary of this research. On the one hand, we tally what was indicated, what was "bought." On the other hand, we detail all your arguments.

Depending on the list we ended up with... because it might be that there are far too many functionalities to approach the user and conduct a similar exercise with them... in that case, we still make a joint cut, which is our recommendation, based on what we heard in the research with you.

‍

‍

How long do you have to wait for results?

‍

Ilona: How long can such a process take?

‍

Radek: If we're talking about an internal buy-a-feature exercise, it's two weeks. If we also include the process of discussions and research with users, the entire process will take four weeks.

‍

Ilona: So we can say that we can start with a very large cloud of functionalities, and after four weeks, we can end up with a tested list. We have our priorities sorted out regarding what we should include as the next feature on our product roadmap.

‍

Radek: Exactly. But let's remember that buy-a-feature won't tell you 100% what your user will pay for. It will suggest what your user *might* pay for. And that's already very valuable.

Thanks to buy-a-feature, we can reduce the risk that might arise if we make a mistake, if we launch something based on what we merely assume.

While intuition very often doesn't fail us and is a great tool that should be listened to, because it's developed through our experiences and it's not something out of this world, but rather the work of our brain... it's still worth asking the user, worth discussing, before we implement something, before we spend money on something.

Ilona: And another problem this exercise addresses is a certain impasse. When we discuss internally for weeks without even arriving at a list of key functionalities.

On the one hand, we could all discuss it as a team for a month and get nowhere, or after four weeks, we could have answers from users.

Types of buy-a-feature

Radek: As I mentioned earlier, the buy-a-feature mechanic is very versatile. You can create various research scenarios based on this mechanic, and the exercise itself can take different forms.

This can be done online, for example, by using Miro boards, with short descriptions, photos, and iconography. You can also prepare tools and meet with the team or a user offline.

An excellent tool is Monopoly money, which you can hold, test, and divide into piles. You can also use printed cards that feature photographs illustrating roughly what a given functionality is. It's just a matter of choosing what best suits the specific challenge and research goal.

However, as I briefly mentioned, we can conduct this research both individually and in groups. And that also depends on the specific product, because sometimes more than one person is involved in a purchasing decision...

We had a situation where we were researching the consumer profile of a high school student, specifically a freshman. And these individuals, when making a purchasing decision, do so together with their parents.

And here, for example, we had to conduct research in dyads to check the decision-making dynamics. Because on one hand, the child has a need and wants to buy, while the parent is the sponsor fulfilling that need.

So, observing the energy between a parent and child in this case is very important. Let me remind you that the marketing and sales angle then emerges. And then, we'll use the same arguments that a child uses to convince their parent to make a purchase, to persuade our customers in marketing communications.

So these are truly very valuable qualitative insights that can be gained, and we highly recommend this exercise on many levels.

Summary

Ilona: To sum up what we've discussed today...

Clients often come to us with a problem of too many functionalities, unsure which ones should be implemented next.

We, UX designers, can help them using the buy a feature method, which we discussed in today's episode. This method can help with prioritizing items on a roadmap. It can also help us gather information about our users and, for example, about a UX persona. It can assist us when we don't yet have a product on the market, to define it better and give it some structure.

Radek: If you'd like us to conduct such an exercise at your company or with your users, please contact us via our website www.designzima.com.

We can discuss your challenge. Whether you even need it. What form it might take. And we can, for example, arrange a session.

Also, feel free to contact us!So, feel free to contact us!

Thank you very much for listening to this episode. I hope to see you again soon... well, hear you again soon, that is... though I might even get to see some of you in person.Thank you very much for listening to this episode, and I hope to see you again soon… or rather, hear from you… although I might even see some of you.

Ilona:
Ilona: Thank you for listening to this episode, and we'll talk again in the next one.
‍Thank you for listening to this episode, and we'll catch you in the next one.
‍

Radek: Radek: Talk to you later, bye.Talk to you later, bye.

‍

Enjoyed this episode?Did you like this episode?

‍