TEAM

Scale-up your business by building relevant products & services

Radu

Design thinking & customer experience

Hi! I’m Radu! One of the most frequent questions that I get from our clients is: can this be done? We tell people that anything can be done, but building the right thing for the long term can be quite a challenge. Here’s a hands-on process that we use to make sure we are always on topic, on time, and on budget with what we develop.

I have launched products in mobile, web, infrastructure as well as gaming, and each time we decide to build a new product from scratch. First, we take a fair amount of time to decide which technologies we are going to use. Deciding on the right technologies for the job is essential as you, our client, are going to deal with them in the long run.

While deciding on the right technologies for a particular project, we take into consideration:

1. Whether it fills the requirements that the product features need.

First of all, when we start building from scratch, we use an MVP (Minimum Viable Product). An MVP is a product with the highest return of investment versus risk. Not to be mistaken with a mockup or a prototype, the MVP is a functional product that, even if it has fewer features, those features are well built and fully functional. As a one-size-fits-all MVP does not exist, it should be adapted to the industry you are in, the problem you are trying to solve and the competition that you have. With that being said, when deciding on the features that your Version 1 should have, we must go through the following process:

 

  • We separate the must have features from the nice to have features. Fewer features mean that you can launch and market the product faster, validate your idea and get feedback from your customers on what you should improve or add to your product. It’s always important to take into consideration your customers’ opinions as what you might think is a core feature might not be as important for your clients and vice-versa, and this has a direct impact on the future versions of your product.

 

  • We choose just one market segment to start. This market segment will represent your early adopters, and you should focus on solving their problems from the first day you launch your MVP. This will help you get the right product fit. After that, you can scale up.

 

  • You should adapt your business strategy according to your audience. There are two scenarios: you are either entering an untapped market or a (well) served one. If you are dealing with an untapped audience (quite rare nowadays, when technology is evolving so fast), you are fortunate as there is no competition, you have the freedom to experiment, and your audience is a lot more forgiving. Unfortunately, no competition also means that you can’t learn from what others are doing and you have to rely on your judgement of what is best. Also, you should prepare for a lot of copycats. On the other hand, if you are dealing with a served market, you have to be better than your competitors. This means that when you are building your MVP, even if you are choosing just the core features for your product, you may end up with a not very short list, compared with the untapped market scenario where you might only need to do one thing right.

2. We check for the additional features the product might need, the nice to have ones

as the product evolves. This helps us anticipate the changes that we will need to make and ensure that the technologies we are going to use are the right ones not only for the current product but for the future iterations as well. Regardless of what you choose, everything will work in the beginning; the challenges will start when you will have to scale up. However, if we are not sure whether we are going to go with a technology all the way or we will have to swap it at some point, we take this into account in the form of abstracting the sdk/library away from the rest of the code.

3. Having an active dev community isn’t a bonus but a necessity!

We check GitHub accounts, StackOverflow answers and blog entries on the companies’ web sites.

4. Last but not least, previous experience with the tech stack is good to have, but not mandatory.

A good fit with the product needs is more important – developers, in general, like to work with new technologies – and also, you can take advantage of features that enhance your product and make it better than your competitors’. I also get asked a lot whether Java is better than .NET or JavaScript is better than PHP. The answer is none is better than the other as each one has its particularities and pros and cons. Choosing a technology over another directly influences the final structure of the product as well as its performance.

 

Node.js, a very popular JavaScript framework, is lightweight and efficient, which makes it perfect for real-time applications. However, because Node.js does not have a compiler, this means that the developers have to be more experienced; and considering there aren’t that many Node.js developers out there (compared to other programming languages) this could turn up to be a challenge. On the other hand, it’s a lot easier to find experienced .NET or Java programmers. This is another important aspect you have to take into consideration when choosing the tech stack: the more exotic it is, the harder it will be to find developers to grow the team as the product scales up.

 

So now that we have finally got that talk about the right technologies out of the way, you would think that the hardest part is over. No! To make sure we don’t stray from the objectives the product needs to achieve, we have regular meetings with the stakeholders. This translates in a minimum of one meeting per sprint, but usually this happens every other day.

 

Setting a good foundation is important, but this isn’t visible at the product level. We talk with the customer and make him aware that in the first few sprints the work we do is not that visible, but this is going to pay off in the long run as we have a solid base we can build on top of.

 

However, all of our work is visible at any given time as the client has access to the development/staging environment as well as the code repos.