In the final paper we saw how to start organizing to work in a team and what precepts we have to follow when working with a group composed of people from different specialties. Today we are going to talk about which techniques to follow to solve a problem, that is, to develop a software solution.

Whenever we want to approach a problem, we must start by stating an assumption and then work with hypotheses.

<<What? What are you talking about, Pedro?>>

Okay, put like that, without explanation, it's a little hard to see. Suppose we have a problem and we want to solve it. We should not assume that our problem definition is real, because we will often find that it is not. So let's work with assumptions. Let's give an example, which is the best way for you to visualize it.

First we assemble the team. All disciplines (design, development, etc.) need to be represented in the group, as well as experts who can talk about the problem itself. For example, if our problem seems to be that our website has a bounce rate that is too high, it would be important that both the marketing people and the statistics people are present at the meeting.

Once the team is located and prepared, it is necessary to make public certain information that will help us understand the problem and make assumptions. That information would be:

• Analytical and usability reports that tell us how the product is being used.. In the bounce rate example, we would need web analytics data to tell us how people visiting our website behave.
• Information on past attempts to fix the problem. This is only relevant if this is not the first time we bring this problem to the table.
• Analysis of how the problem affects the company's performance.
• Competitor analysis showing how the competition is solving this problem. (if possible).

Well, all of this will help, during the process, so that all members of the group not only understand what problem we are talking about, but also have all the information surrounding the problem.

Now let's start working on the problem. To do this, we must make a problem statement.

What should this statement contain?

1. The current objectives of the product or service.
2. The problem to be solved.
3. An explicit request for improvement that does not specify what the solution is.

Very good. Let's take a more practical example. Let's imagine that we have a SaaS (Software as a Service) that allows other companies to do their general accounting without the need to contract with a bookkeeper. And now let's make a problem statement:

First, the current objectives of the service:

“Our service has been designed to allow small and medium sized companies to manage their accounting in a simple way through an online platform that we make available to them for 20% of what it would cost them to hire a manager to perform the same tasks.”

Second, the problem to be solved.

“The commercial website that is in charge of allowing the registration in our service shows a very high bounce rate (95%). “

Third, express request for a solution.

“We need to get the bounce rate down to a reasonable value (a 40%) and have visitors stay longer on the page so that they potentially decide to purchase our product.”.

Notice that these are three very simple paragraphs, but they allow the group to be very clear about what the problem is and, above all, what we are being asked to solve. Of course, there could be more problems, or this problem could derive from another, but now we are looking at a simple case. The important thing here is to be able to draw assumptions from these paragraphs. Let's see what assumptions we can get:

• A large part of the customers who come to our website are not part of our target customer segment.
• Our website does not adequately explain what we offer.
• Our website is not well implemented from a technical point of view.
• So few people come to our website that the bounce rate percentage is inconclusive.

We could come up with more assumptions. Each member of the team would give his or her opinion and, for sure, we would get many more than these four, but to be able to explain how to work with the hypotheses is enough for the moment.

Now that we have a list of assumptions, it is time to work with the hypotheses. The problem is that we have four assumptions and now we could ask ourselves which ones should be prioritized. The answer on paper is very simple: first those that involve more risk for the business.

So once we have decided which assumption poses the greatest risk to us, let's work on its hypothesis. For this example, I will choose the first assumption: a large proportion of the customers who come to our website are not part of the customer segment we are targeting..

Note that if this assumption were true, we would have a serious problem, since we would not be reaching the desired customer segment. Or, even worse, we could discover later that we are reaching the segment we were looking for, but it turns out that it is not the right one for our product and does not need our solution. But let's take it one step at a time. First, you have to take the assumption and transform it into a hypothesis.

How is this done? Let's look at the normal format of a hypothesis:

We believe this statement to be true.

+

We will know that we have done well/badly when we have the following feedback from the market: [whichever is applicable].

We see two clearly differentiated parts: statement about something we consider true and statement of the result that will show whether we are right (or not).

Now let's apply it to the first assumption we have made: a large proportion of the customers who come to our website are not part of the customer segment we are targeting..

The hypothesis could be something like this:

“We consider that the people who are coming to our website are not our target audience.”.

“We will know this is true when we revise our marketing strategy to target the right customer segment and then verify that the bounce rate has decreased.”.

And it doesn't end there, because, in this case, we will have to review and make new assumptions and hypotheses about what went wrong when we conducted our customer visibility campaign.

Let's take another example. Let us imagine that we now create a hypothesis on the following assumption: our website does not adequately explain what we offer.

It would be something like this: 

“We feel that the people who are coming to our website don't understand what we are offering them.”.

“We will know this is true when we change the content of our landing page to make it clearer and more intuitive, and then verify that the bounce rate drops to 40%.”.

Or we can also create more than one hypothesis on the same assumption. Let's put another one:

“We feel that the people who are coming to our website don't understand what we are offering them.”.

“We will know this to be true when we conduct interviews with potential customers in which we show them our landing page and ask them about its content and the value they place on it.”.

Conclusion - Assumptions and Hypotheses

These examples are very generic and simple. They are enough to get the idea. In day-to-day business the assumptions and hypotheses are often more complex. The important thing is to understand what the problem might be, what solution we can provide and how we measure whether the solution has worked or not. 

We could talk about sub-hypotheses, protopersonages and other aspects related to the creation of assumptions and hypotheses, but today's article is about making you aware of the concept so that you can start working with it.

If you didn't read the first part of this series, I recommend you do so to have a solid foundation to build on. You can find it here: How to work in a team (1/2).