Product Development for Startups

Sometimes these companies have a marketing team, or already work with a design studio for corporate image and UX/UI, or even have part of the development team in-house but need certain expertise they don't have in-house. That's where we come in. We have the technical know-how and experience with Symfony to turn those ideas into a robust first version, allowing them to quickly validate the proposal on the market and apply for new rounds of funding if necessary.

Anyone who has tried to build a development team, especially recently given the shortage of specialists at all levels, knows that it can be a long road filled with trial and error, especially for startups in their early stages. It's not just about finding the right people, then training them in the company's vision and integrating them with the rest of the teams. It's an investment of time and resources that many companies often can't afford in their initial phase.

Before we start digging, as we come from a technical background and have traditionally always been oriented toward that, rolling up our sleeves and getting to work, it's worth stopping and briefly analyzing whether or not we want to make this product and whether we have the resources for it. I'm not referring to Softspring here, to us, but to the client itself. Perhaps the conclusion is that they do want to make it, but we're not the right partner, and finding that out as soon as possible is good for both parties.

In the book Let's get Real or Let's not Play: Transforming the Buyer/Seller Relationship ( link on Goodreads ) a methodology is mentioned, ORDER, in which the first three letters would be Opportunity, Resources and Decisions, which are very interesting in order to consider what I mentioned in the previous paragraph.

In the case of the Opportunity, what are we trying to solve, what is the problem, why isn't it being solved before, why hasn't the company solved it before (lack of equipment, etc., but clarify), how do we measure the success of the solution, if we reach it.

For Resources, what people, at what level, will be involved on the client's side, when do they expect the results, will they be able to get involved in the project to the extent and in the way necessary, will they provide Softspring, in this case, with access to the right people, how much money do they want to invest in the solution, do you expect a fixed, initial cost of an amount, or is the company prepared to assume a certain monthly expense in technology?

In Decisions, when we're talking about different solutions to the problem, in the details, who will make the decisions, how they will be made, at what pace and process, will we have access to those people who will be making the decisions?

Once you understand the client's needs, available resources, and the decision-making process, the next step is to model the solution. This means transforming all that knowledge into a concrete action plan. Here's how we would approach this phase:

Based on the identified opportunity, we'll detail what the product will and won't do. Here in this case, in the initial phases, unless there is infinite money and infinite time resources, it's much more important today to decide what not to do than what to do.

This is often referred to as MVP, Minimum Viable Product, and much has been written on the subject, but here we want to capture the final product, the solution to the real problem perceived by the client, and define the minimum approximation that could be a solution to said problem.

Looking at the image above, for us the minimal version of the product would be the whole slice of pizza, but many people end up making the part on the right, a "complete" round pizza, but removing ingredients until you're left with just the dough.

Okay, so how do we define a minimal version of the product that resembles the full product, that slice of pizza we were talking about (talking about pizza so much is making me hungry).

Whatever we do today, we can structure our solution into parts, components, chunks that will communicate with each other or with other external parts or systems. This is very common these days through APIs, which is why there is so much API development.

This work of thinking of our solution as parts that talk to each other, components, will allow us, depending on the resources we have, to decide what we won't do, what we'll use an existing external component for, and what other things we'll custom-make. Not only that, in many cases, we may have already understood beforehand that our solution will need to connect to many external elements (for example, we want to use a Stripe payment solution and/or send emails with Sendgrid); thinking of our solution as a set of connected components will make this easier for us.

I'll digress here to say that componentization doesn't mean doing everything with microservices ( we have an article on the topic ); we can have many of our components in a single monolith. This is more a functional separation than a technological one; we'll think about how to solve this later.

By breaking down the MVP into distinct modules, we can iterate quickly, test and adjust on the fly, and ensure that each part of the system communicates effectively with the others. Whether we're integrating a database management system, leveraging a third-party data analytics platform, or connecting with other digital services, our goal is always the same: to build cohesive, robust, and scalable solutions that not only meet the product's current needs but are also future-proofed.

In this approach of breaking down and looking for which components to build and which not, we can sometimes see that a certain component is missing, one that we don't have at the moment, that perhaps at some point we could develop ourselves, but that perhaps temporarily or in a validation process, we can connect to an external system that we will then migrate.

While some migrations are expensive, sometimes the extra cost is worth it to focus on other, more valuable parts of the solution, reach validation sooner, and determine if our solution fits the market sooner.

There are many external products and solutions we can connect to to expand and complement our product. We'll list them in future articles, but for example, Airtable, Notion, or providing APIs to connect to from Make (formerly Integromat).

After identifying the solution, the next step is to break it down into a realistic and achievable roadmap, deciding which parts will be done first, which parts, as we said, will use existing external systems, and which parts will not be done initially and will be done later.

It's not just about launching an MVP and that's it; it's a continuous process of growth and adaptation. We focus on planning not only what will be done in the short term, but also on anticipating and preparing for the next stages of development, always aligned with the startup's vision and capabilities.

At Softspring, communication isn't just a formality; it's an integral part of how we work. We immerse ourselves in your project, understanding your needs and adapting to them. This close collaboration ensures we're always on the same page and can adjust our strategies and actions quickly and effectively.

For this reason, if we want the product to be successful, it is important to have access to the people who will be able to make the decisions, as we mentioned in the ORDER methodology above.

At Softspring, we adopt a continuous delivery approach to ensure we deliver value to your project at every stage. We rely on agile methodologies and iterative development cycles, which means your product not only gets to market faster but also constantly evolves in response to real user feedback.

This methodology allows us to make regular adjustments and improvements, ensuring that the product not only meets but exceeds market expectations and the evolving needs of your startup. Continuous feedback is key to this process: it allows us to fine-tune and perfect the solution, ensuring that each iteration brings significant and tangible value to your business.