1.  What basic steps does a SME need to take to design its digitalization strategy?

I believe that the most important thing is to start with the processes. Many companies say they want to digitalize because it's a trendy word they've heard, but often they haven't defined what their processes are.

The first step would be to define what my current processes are. Then, I would try to document them in a way that is understandable. Once I have all the processes, I would choose which process to digitalize, prioritizing those that are most susceptible to digitalization.

Once I'm clear on which process I want to digitalize, I would sit down with the different users of those processes to understand their requirements and needs regarding the chosen process, simply by talking to them and asking, "What do you do here? What do you do there?" There, you'll likely identify a lot of manual tasks, and you'll also identify things that they need.

Once I have the list of those things I need, that's when I can look for the most suitable tool according to those needs. Many times people go for the tool without going through the users' needs, and that leads to choosing the wrong tool, because the important thing is not just the tool but probably those user needs.

Here's an example: imagine I want to digitalize a process of my sales team, from leads acquisition to generating the commercial proposal and following up on it. So, what I would do is define what my current sales process is, document it so that everyone is clear on it, and from there I would sit down with the different users to understand their needs in this sales part, and then look for the best tool. In this case, since we're talking about sales, it could be a CRM like HubSpot, Zoho, Microsoft Dynamics, Airtable, or any tool of this type, but always starting from the process and the user's needs.

2.  How can SMEs and freelancers identify the needs of their customers before developing successful digital products?

If we are talking about customer needs, it would also be by being very close and talking to them. Here what is usually done is to use market research techniques, which can be either qualitative or quantitative. The qualitative ones are one to one interview, or focus groups, which are discussion groups where you have several customers.

The quantitative ones, I'm sure many of us do it on a daily basis, are surveys, which can be surveys to my own database or surveys to a panel of customers where I outsource the launching of this survey to another database.

3. What indicators should a company measure to evaluate the success of its digital products?

This depends on the product, the industry and the sector. In any case, the ones I like the most are what I call "user activity indicators" which is what is called in the product world "DAU, WAU and MAU"; DAU stands for Daily Active Users, WAU stands for Weekly Active Users, and MAU stands for Monthly Active Users. Typically companies, depending on your digital product, use one of these three. If you are Facebook you have to measure DAU, because what you are interested in is to measure what percentage of your users enter every day in your application, because it is a daily consumption application. If we go back to the customer area we were talking about before, in an insurance company customer area you don't enter every day or every month; you will have to measure the MAU - or even the "QAU" (Quarterly Active Users), which would be how often you enter every three months or once a month, because recurrence has nothing to do with it. This metric indicator is fantastic, because it's telling you, out of all the users you have registered, how many are being active.

4. What tools and methodologies are most effective for digital product development?

I can say three. One I'm sure many people know; it's the scrum methodology, where you develop based on a series of sprints. That is, instead of raising all the requirements of a digital product at once and then go several months to the development team and deliver a final product, do it in small blocks and small sprints of time, two or three weeks, where every two or three weeks I deliver a part of it, collecting feedback from it, and go iterating.

The second tool I use, which I love, is called "user stories". User stories are based on the fact that, when you have to design a digital product, instead of listing features, you list what are called user stories, which follow a structure that tries to put you very much in the user's shoes, and you define a story.

The third tool is to use what is called in the design world navigable digital prototypes. It consists of, before going to development, and using tools like Adobe Xd or Figma, being able to paint what those interfaces look like, and send them to a development team. I have seen many times that we skip this step and it is the development team that makes the design decisions, and that is an absolute failure because they are not experts in it, and then many user experience problems occur.

5. What recommendations would you give to an SME that is considering launching a MVP (Minimum Viable Product)?

I don't really like to talk about "minimum viable product". There is something that is becoming fashionable, especially in the American world, which is called, instead of the "minimum viable product", it is called "minimum awesome product", that is, like the minimum viable product, but wonderful. I like this concept much more because I think that, sometimes, when we develop minimum viable products, we develop them with that vocation to test them, but they are not so well done, and in the end, we receive bad feedback from the client, and in the end the test is not successful. I think the "minimum awesome product" is much more interesting because you get to focus on designing a minimum viable product of a very small functionality, but that is made in a fantastic way, with a good user experience, much closer to reality, so that the user can see a well-defined and finished product, but only of a small functionality.

The other thing I would recommend is that, in addition to designing that prototype, I would define a concrete testing plan, defining beforehand what success means and what failure means, because I have seen many times that, because of what is often called the sunk cost bias, which is that, as I have already spent a lot of time doing something, and then I do not want to turn back because I think I have already wasted a lot of time doing it, then I try to convince myself that, regardless of the result, I have to get it out, yes or yes. To avoid this bias and subjectivity, what I would do is to define some hypotheses, which establish that, if in the testing of this minimum viable product these results are produced, I go ahead, and if in the testing these other results are produced or I do not reach this minimum result, I go back. This way you are avoiding that sunk cost bias and fulfilling the fair objective of a minimum viable product, which is to test something with the minimum possible resources.