In my work as a Product Designer, I’ve seen that most products fail because:
- They miss to identify what behaviors they need their users to do to perceive the product as valuable
- They don’t have a strategy to get them to that point effectively.
- And they forget to design to provide value to each one of the roles involved in the product.
The objective of these models is to ask you the right questions for you to design centered on what matters most: driving user behavior to generate value for them.
This article deals with Models #4 and #5 that help you find
- What behaviors to design for.
- How long should you spend trying to solve the problems they propose.
You can check out this example if you want a quick tour of the method
In this article, we have identified the growth, nutrition, and reproduction behaviors required for your product and ensured that they make the product ecosystem viable by checking that they provide value to each actor. Without one of these behaviors, the product would not work by itself. In this second article we tackle the issue of prioritization.
#4 Target Behaviors Definition — Behavioral Design Models
Throughout this process, your development priorities have probably changed; issues that did not seem relevant have risen in importance from this perspective. It is usual for these priorities to continue to evolve. The objective of this model is to find some certainties in this regard, order your goals so that you set a course in an ever-shifting ocean.
By this point, we should have three unsorted lists resulting from updating the first model with the behaviors found in model Model #3 -Type of needs. These are the Target Behaviors of our product. Our goal as product designers is for these behaviors to happen. So why prioritize a list of essential behaviors? Unfortunately, throughout product development, situations often create the illusion that a part of the project is more critical than it is.
An example of these illusions is the bicycle parking effect, described by C. Northcote Parkinson. Parkinson noted that a nuclear plant design committee spent disproportionately more time discussing trivial matters, such as bicycle parking supplies, than addressing the plans for the nuclear plant itself. They preferred to treat the simple task in length and differed from attending to the challenging issues.
The example is generalized in Parkinson’s law which states that:
“ The time spent on any aspect of the agenda will be inversely proportional to the amount [of money] involved.”
A nuclear reactor is a complex object, which requires a lot of information, so the committee participants assume that the experts’ recommendations are correct. On the other hand, bicycle parking is where the participants feel more secure giving their opinions and establishing their convictions in the project.
In my experience, the most common of these illusions is to consider that some functionality is why the product is not a success. It leads teams to focus on specific functionality, which generates value only for some actors and neglects others fundamental to its success.
To avoid these illusions, we need an objective way to establish the importance of each of these behaviors that we want to generate. We need to know how much of our time and effort we will devote to the task.
We have been working under the assumption that a product is a life-like thing. In life, the first necessity is to grow. A product that does not grow in a user, those that fail to show users value, do not have the opportunity to add value regularly and have even fewer chances to be recommended. Therefore, first and foremost, the product must be used for the first time by the user. A seed grows before it can sustain itself, and only when it matures and has excess energy, does it reproduce.
That is the reason why free trials are successful. When a product can show its value regularly, this is the best possible adoption strategy.
Objective behaviors categorized as “Grow” should, in principle, have a higher priority. The behaviors in Nurture take precedence over those listed in Play because if your product shows value periodically to a user, they will usually take care of reproducing it, even when you have not designed anything for this to happen. As they say in Jurassic Park, despite the dinosaurs being sterile: “life finds a way.”
For some actors, the value is evident, and the effort is minimal; for others, not so much. The objective is to prioritize the design of the behavior for the actor in which the product is providing less value. The diagram constructed in models Model #2 -Actors Requirements and Model #3 -Type of needs will be helpful to prioritize within lists.
Remember, Value depends on context.
We know that resolving survival needs is a must if the user doesn’t have it covered, but it could be of little value to those who do. In turn, Relationships and Personal Growth needs are valuable when the survival aspect is covered.
The model
Make a list for each actor and rank each target behavior according to its value received relative to the actor context. There is no need to quantify value; the objective here is to create an orderly list. Remember that we already defined Grow behavior as precedence over Nurture and Reproduction, so you need to qualify them within categories.
The last step is to combine the lists into a single target behavior list to rule the MVP development. For this, we will rank actors according to (you guessed it) the value they receive. The objective behaviors of the actor that gets the least value are a priority because they are the ones we must devote more attention to, the weakest point of the value offer. But, it is also vital that each actor gets something out of the platform or won’t engage, so we need to plan for them. Therefore, we cannot focus on just one actor.
Take the behavior that provides the most value of the user that gets less out of the platform. Then continue with the next actor in the “get least value” and select their most valuable behavior, and so on. In the end, you should have a prioritized list of Target Behaviors. This list helps you focus on designing value for users we need but are not easy to engage.
There are still some more optimizations you can perform. There may be duplicate behaviors; different actors may need to do the same thing. In this case, that behavior becomes a priority (we cover two actors with the same effort), so we place it at the beginning of the list. It is also likely that there are behaviors that we cannot realistically affect with our product, it is good to know that they exist, but we must rule them out of our prioritization for design.
Finally, Draw a line under the last nutrition behavior. The behaviors above the line are necessarily part of our MVP.
#5 Design Effort — Behavioral Design Models
How long should it take to design my product? Spending too much time in one feature is one of the largest pit traps that lay in your way to launch. Use this model to estimate and decide how long you will spend with each one of the problems.
After Model #4 – Target Behaviors Definition, you have a prioritized list of behaviors that you need people to perform to get something back out of your product. This list ensures that everyone involved receives some value (even if it’s just a perception of value).
Having reached this milestone, you could spend as much time refining a feature to get users to do it. But beware, this is one of the largest pit traps that lay in your way to launch. You could end up spending valuable time over-defining a product. On the other hand, it could be the case where you cannot tackle the challenges before a particular window of opportunity or that the project is so challenging that you may be better off walking away from it. Scoping is key. This section deals with how to get past this stage
Software developers have found a system using the Fibonacci sequence (that has been battle-tested) to estimate the complexity of proposed tasks for development. For those that are not into math, the Fibonacci sequence is the series of numbers that results from adding the last two numbers and goes like 1, 1, 2, 3, 5, 8, 13… And, believe it or not, this method is rooted in behavioral sciences.
The trick is to find the most straightforward task in the lot or think of a dummy task that is the smallest chunk of work you could complete. Then, assign that task a 1 in complexity. Then compare all other challenges in terms of complexity to this base task and with each other. Is something more complex or roughly equal? But, remember, instead of using a continuous scale (for example, 1 to 10), use the Fibonacci numbers.
When estimating task complexity using numbers from 1 to 10, or 1 to 100 is easy to argue if something is a four or a five. They both fall into the “medium” complexity range. However, the Fibonacci sequence, which grows exponentially, forces you to decide if something is a 3, a 5, or an 8. We are still selecting from a scale, where each number has a given position in the list, but it feels different.
The Weber Fechner law explains this phenomenon:
“the minimum increase of stimulus which will produce a perceptible increase of sensation is proportional to the pre-existent stimulus.”
Of course, this law has larger implications on perception and can help design a better product. But in this case, it means that the difference between 3 and 2 feels more significant than the one between 9 and a 10. Moreover, that decrease follows a logarithmic shape (I’m again talking to those into math), so using an exponential scale can help us battle this bias.
The model
Go over all the target behaviors and estimate how complex it would be to find a suitable solution to get people to perform it. For this, Consider your knowledge of this particular actor and if you have examples of other products that manage to do it.
Filling these models results on a prioritized list of behaviors to provoke your users and an estimation of how complex it will be to design them.
In the next article, we will start working on the actual design, following the priority order we defined before, but never forget this complexity estimation! It will help you come to terms with a good enough solution and move forward to the next.
Here are a set of quick steps to construct the models.
Model #4 — Target Behaviors Definition
- List all known actors in a row.
- List all behaviors that show value to each actor in a column.
- Order the behaviors in descending order according to the value they provide to the user. Follow the order defined by the ERG theory of needs.
- Reorder the actors in ascending order of value they receive from the product (the one that gets the least value first).
- Numerate the behaviors from in the resulting table, from left to right and top to bottom.
- The resulting list is the order of target behaviors to tackle.
Model #5 — Design Effort
Estimate how complex it would be to find a suitable solution using only numbers present in the Fibonacci sequence.
