Why your tech team should do product demonstration.

I’m a full-stack engineer at Stackeo. Last month, at a conference called SIDO, all team members were trained to do product demonstrations. This is a crazy idea, all members, even the developers were training, and you will not believe it but it worked!

You wonder but is that not a job for salespeople and promoters?

The answer is yes. But what if the team who develops the product learns to demonstrate it?

This post aims to explain two things, the first is to talk about my story as a developer out of my context (code, PR, review, git, error, etc.) interacting with others to explain the product based on use cases.

The second point is what benefits this experience brings to my evolution and the team.

Before starting I will explain what SIDO is in a few lines: SIDO is an event for IoT, AI, Robotics, and XR in Europe. It took place in Lyon, France a month ago and I had the pleasure of being part of it as an exhibitor.

I’ll explain it with the following points:

  • How to fail?
  • How to hold their attention?
  • The important elements, the magic elements.
  • In which other cases can I use the product?
Photo by Sigmund on Unsplash

The tech team just thinks about the technical side and not the goal of the product, so you can be incredibly good at backend or frontend but you have no idea who you are making the product for.

It’s difficult for us to have an in-depth conversation about a non-development environment, our issues are related to the code and not the product field.

To this, we add that we do not have the know-how of people in the field of sales or marketing and the methodologies behind all this and therefore the first attempts were a failure.

How to fail?

  • Aggressive interception, like: hi, can I ask you several questions for a study? Or we are doing a survey, do you have 30 min to answer? the most obvious answer and big no.
  • Focus on the objective rather than generating a conversation
  • Not think about the impact of time on others, it is not the same to prevent that I am going to take you 5 min to 40 min for an explanation
  • Missing the good ice-breaking, we don’t all have the same effect for the same icebreaker. You could find someone with sympathy and the phrase “hello are you enjoying SIDO” works, but with others, it is not the same result.

Once we discover how to fail we can take this learning to intercept a person to generate a conversation.

We must identify some characteristics to generate a natural conversation. Some of these characteristics for example are: identify the environment, the audience, and then, if he/she is in this segment, what is his position, such as his current job/project.

After this, what will be the phrase that will generate the conversation?

In my case, I was in SIDO where there could be an innumerable number of actors, people who combine various fields (IoT, robotics, XR, etc.) as well as with different positions (developers, suppliers, students, etc.).

We already know the environment, now the person must work in the field of IoT, if so, what is his current position? Business owner? IoT Solution Provider? or manufacturer?

After what we have retained from ‘How to fail’, we can take that the phrase cannot be aggressive, we must have empathy and focus on the conversation and not on my goal and finally, it is to break the ice. We already have all the ingredients.

How to hold their attention?

It sounds like sales on television but one of the very important factors is: being able to know what problems are solved with the product that you are presenting in the day-to-day life of your interlocutor.

In addition to this, you must always have empathy and be interested in the client’s story, what does it do? how does he do it? And about all what is his problem?

Once talking with several clients you will realize that a large part has an element in common, a problem that they share, and when you find them you will be able to talk to all of them in the same way and adapt this little by little depending on how the conversation is outlined.

In my story within the event, we had to demonstrate how our clients could financially plan their products and improve decision making. All this is in the context of the conversation and the environment in which the user is.

As a developer of software I spent months in review, building components, widgets, commands of CI, and finishing user stories, my focus has been on crafting code (all described in my job description 😁), and for the internal demonstration, I was a complete disaster.

I knew how to work the product what is the input and the data then it will be returned, the path, in sometimes where is the issue from, but I had not any idea to how the user could resolve her problems with.

And one day I assisted in a user interview with the CPO, I could not contain the desire to explain to the user how to use the product.

Seeing him lost in the middle of an input text was terrible for me. Why are you lost in navigation? why doesn’t he know what the input was? and that’s where

I realized that I was thinking like a developer and not as a solution provider.

Then months before SIDO one of the founder had the idea to train the whole team on how to use the products, not how it works, but how to use them on a specific problem.

And then the weeks before SIDO, again the same man has the idea to train the whole team in the product demonstration in front of the real user, doing role plays.

This has been a nightmare, how do explain the why and how of the product? What are the benefits of using it? How can you solve your problems? And why is it important to someone else’s business?

Despite all the countless emotions I had, I have accepted the challenge like the other members of the team. The first time I felt nervous, small, and unprepared to do this exercise? I felt that I did not have a good flow or, magic power to do it, I felt that I did not know how to convince another to use our product.

And it is there where I began to listen to the other members, how they spoke, I began to take notes of keywords, what I like the most about the product and how the product is for me, I also wrote down the bad points of the others and final the comments they made me when it was my turn to do demonstrations.

The important elements, the magic elements.

Maybe you know him as an MVP or as a feature or as something magical. In all the products they have elements that solve a real problem in the market, if your product does not have them, I am sorry but you need to do another business model and market study.

But as a developer, you have to convince yourself why the other will use your product and not ____ (fill in the blank with your competition number 1).

Don’t explain that with a complex explanation, you should be able to explain that in simple words, as short as possible, and in a very conversational way.

For me with this product, you could show the best scenario so that your client can make the right decision in your IoT solution.

If you know how to explain that, can you solve a simple problem with the product?

Photo by Michal Matlon on Unsplash

The main way to know that you understand everything about your product is to solve problems, in order of complexity you will have the best understanding about the product.

Once you have completed this step you will be able to identify the limits of your product and in which case I may or may not use the product.

As I described in the previous point ‘why you should know, you should do training sessions to solve real problems. It’s like your training to understand a new framework or library or a new cooking recipe that starts with the basics and progresses to the more complex.

Remember, don’t think like a developer, think like a user.

In which other cases can I use the product?

In my case, we are building a SaaS to compare financial scenarios of IoT solutions.

We have the specific field which is IoT, and the second element is financial comparison. Make this same comparison with your product, what is the application field and what is its element of focus of result, what does your product do?

After this we create a simple scenario to test it, imagining a basic use case, to this exercise we add values, always placing ourselves in the position of a user, that is, not writing data in input in an aggressive way without meaning, or clicking on the links to see if the page is displayed, for this use an end-to-end test.

More specifically in my story, let’s imagine that we are a company that has a construction tool tracking solution, we must convince our clients to adopt their solution, their speech is low maintenance cost, but they do not know how to talk to their client In this case, we need to create a scenario with minimal real inputs (for example, replacement and maintenance costs) and simulate various scenarios to convert to our future client. Once done, enter more information to transform this example into something more realistic.

And boom! It’s solved, a case with your product, try to keep it simple.

What did I learn new?

Once this adventure is completed, as a developer you will feel different, in my case it does not matter if I spent several years freelance (here you focus on other things), the responsibility of demonstrating a product in a field that I do not master is not an easy task.

You realize that the people who will present the product do not care if there is clean code if you have good practices within the code.

They want to know what you can do with the product and how many problems are solved.

I am not trying to say that all good practices are wrong. They are good at code development and rapid understanding by other members of the technical team.

It is a key element for a successful business, but it is not fundamental. The purpose of the product is to find people who will love to use it and feel that this is the solution to one of their problems.

In short, this practice improves you personally in:

  • Know how to connect with people, in the sense of generating a random conversation to show them a product.
  • Learn how other companies handle their problems.
  • Get to merge your technical knowledge with the product.
  • Know how users will interact with your product.
  • Learn to help identify the problems of your interlocutors.
  • Know how to prepare to answer questions about the product.
  • And finally, to know the product in-depth to be able to propose significant improvements within the development

It does not matter in which part of your roadmap you are in your product, launch, or development, try as an internal practice to test the demonstrations of the technical team, you will be surprised at what can happen, do not leave this only for the business specialists, involve your team that develops to talk about your product.

Full stack engineer, trying to change the mindset of others, coding is not always writing code.