In the start-ups world, not everything revolves around ‘tech’, and specifically, having tech knowledge or work experience isn’t a mandatory ingredient for success. As a non-tech founder, though, you might face some challenges, have concerns, and a difficult time familiarizing yourself with the ins and outs of software and app development.
From getting to know the process of requirement analysis, and how a development company distributes the budget and resources to adjusting to regular collaborations with product managers, you might feel puzzled and ask yourself ‘why’ a lot of times.
Well, here are the answers to some of the most common questions non-tech founders have about digital product development we gathered from members of the Softbinator team.
1. Why do product development teams apply an Agile approach?
As Arie van Bennekum, one of the co-authors of Agile Manifesto (2001) is always saying – in a nutshell, we work Agile for a simple reason: to avoid delays. Agile allows practitioners to build faster and smarter, from fast prototyping, to MVP and fine-tuning. Also, an Agile approach gives the flexibility and the ability to quickly adapt to change
Daniel Ilinca, Chief Executive Officer
2. My product idea is simple. Why do I need a full-stack product development team and not just 1 software engineer and 1 designer?
In theory, you can build a product or an application with just 1 software developer and 1 designer. However, this means that you, as a client of a software development company, would need to provide full-time qualified jobs of a product manager, product owner, software architect, QA engineers and any other roles that your product would need to be completed.
Otherwise, you’d have software developers who take up additional roles, like product manager or QA, for which they may have limited to no expertise. This situation could lead to either a significant project delay, poor product quality, or both.
That’s why our recommended way to build a quality product is to start with a core team that includes: 1 Software Architect (even if this role is required only in the first phases of building a product), 1 Back-end Developer, 1 Front-end Developer, 1 QA tester, 1 UI/UX designer, and 1 Tech Lead (acting as product owner) – who guides the entire development process and aligns the team on the product’s goal
Nicușor Eftene, Director of Engineering
There’s no “one solution fits all” solution regarding a product development team. If you choose 1 developer and 1 designer, you should be aware that most of the time the interaction will evolve around completing a set of tasks, and that’s it. Even the most skilled developers don’t have expertise in all areas of product development.
Our team faced a situation when the client decided to have only one developer to handle front-end, back-end, DevOps, QA, and maintenance. The developer managed everything, but for the DevOps part, he only focused on ‘making things work.’ The outcome was a good running app, but with several security issues, backend bugs that were discovered after the release – all these affected the client’s business.
For instance, without a product manager, clients or a person from the clients’ side will come up with ideas. But if this person isn’t a product manager, the result could be an app with many features but without a clear direction. In other words, a digital product with nothing to set it apart from the competition that ultimately won’t succeed.
Having a complete product development team helps you build a scalable, quality product, starting with product managers who can understand your business needs and translate them into technical requirements, to architects who can design the system based on your requirements and KPIs, developers and QA specialists who ensure the quality, and other roles in between.
Cristi Spiru, Software Architect
3. I asked the software development company for a clear price on my product idea and they’re not able to provide me one. Why is that not possible?
Any product development process should embrace “the change”, from technology innovations to product requirements. With markets constantly changing and consumer needs shifting during your product-market-fit journey – these factors make the price estimation of a product development process very inaccurate. Setting a fixed-price from the beginning isn’t a good recipe. It actually brings limitations to your project, and you can end up delivering a product that has all the elements of success from one year ago but has no value for today’s users.
Marius Băisan, Chief Technology Officer
4. Why don’t software development teams work with predetermined deadlines or project timelines? How can I make sure the product will be completed in the predefined agreement without fixed deadlines? What work process should I look for?
There are deadlines but the right approach is to start with a budget and work Agile using a top-down process, focusing on the most valuable features first. You can always get only two from the triangle: good – fast – cheap. Through a continuous selection process we ensure the “must” deliverables fit in the solution using the MoSCoW method to prioritize the mandatory product needs, like:
Must Have – the non-negotiable, top-priority product requirements that make the core of the product
Should Have – important but not essential elements; these would add value to the product and can be used for future releases
Could Have – functionalities that fit in the “nice to have” category but without them, the product is still viable
Won’t Have – requirements with the lowest priority that you can exclude, at least in the MVP phase.
Sometimes clients change their mind, which is normal and many times necessary. That leads to having product teams add new things in the backlog, but it comes with a trade – either we need to increase the budget or cut some existing backlog items to make room for the new ones.
Daniel Ilinca, Chief Executive Officer
5. Why can’t I skip a step in the development process, like the product discovery or testing phase?
Statistically, 9 out of 10 startups fail, and most often it’s due to poor market fit.
Skipping initial steps, like product discovery or not allocating time for a testing phase leads to a higher chance of failing to achieve product market fit. Validating your idea through product discovery reduces the overall risk of not focusing on what is required to help you get a good fit.
Target market analysis helps define the need that your product solves, so you can refine your product vision and goals. Test phases are a useful extension of product discovery that help further refine the product through feedback and see how a small pocket of your market audience uses your solution.
This data is invaluable in shaping the way your product will look like, and how it will solve the identified need. After going through these steps, your product vision, goals, and priorities might be completely different from the ones you thought about initially.
But by taking the time to understand your market and test your solution, you’ll have a better chance of being able to make the right decisions to ensure that the product you build is the product the market needs.
Alexandru Leca, Senior Software Architect
6. Why does expanding my product’s scope and adding a last-minute feature take much time?
Usually, when you start a project there is an initial “scope for the work” that has been agreed upon and for which the team has budgeted time and effort.
For example, let’s say the scope is to develop 10 features for an app. If we then add another feature to that scope in the final quarter of the time allocated, that means adding an extra workload to the team, but also affecting the other incomplete features that are still in development. This will cause you to fail to meet the desired timeline.
Basically, if you add more work, you need to be able to increase the scope, which involves changing the timeline and maybe even moving feature development to a different order. Sometimes adding an extra feature might have an impact on the features that were already developed and now need to be revisited and refactored.
Alexandru Leca, Senior Software Architect
Adding a new feature towards the end may be a lot more difficult than it seems because the architecture was decided based on certain use cases and/or quality of service. Changing this towards the end may involve new analysis rounds that may impact already developed features.
Sometimes even changes that seem trivial may need a lot of code rewriting, which will lead to new test cases, new testing and new rounds of bug fixing. For instance, having an endpoint that handles just one request and then a change comes regarding a batch operation.
This may seem as easy as iterating over the list and continue with the job you were already doing. But these questions arise: “what do you do if just one of the operations fails? Do you rollback the entire batch or not?” You also need to consider testing – this becomes a lot more difficult as you need to test with different workloads.
Radu Diță, Senior Architect
7. Will I speed up the development process if I double the team size?
It depends. On a well-managed team with a good leader who has clear specifications for the next months, you can aim for almost doubling the progress by doubling the team size.
For this to happen, though, you need to have 3 prerequisites:
1. already have a balanced team in place
2. new included members have the right experience and expertise for the project
3. adding more team members shouldn’t occur in a critical phase of the development (e.g.,. integrations tests).
Since these 3 prerequisites never happen all at once, in the best case scenario, you should simply aim to have an increased outcome for the development team. If you see increased progress in the first sprints, that means you’re on the right path and you managed to speed up the development process.
But you can face two other possible scenarios:
1. the development speed stays the same. That may happen because the initial team spends a lot of time onboarding the new members.
2. The development speed is slower. The possible cause of it can be the fact that beyond the time spent with onboarding, new members need more time to become productive and keep up with the members from the initial team.
Of course, lots of other possibilities exist for the 2 scenarios from above.
Nicușor Eftene, Director of Engineering
Depending on what’s the task/goal, doubling the team could help increase the development speed but not double the efficiency. Some processes cannot be done in parallel; increasing the team also increases the complexity of managing it, thus it would require extra resources.
For instance, if you either add more team members or double the team size, you will also need a Scrum Master to align the entire team, solve any workflow problems, and ensure everyone streamlines the development process in each sprint.
There’s also the time resource: with more people on the team also comes the need for more communication sessions, and overall, it can become counterproductive. Most times, a 5-6 person team can show higher productivity and less communication bottlenecks, as opposed to a single team with 20 members.
Cristi Spiru, Software Architect
Conclusion – What To Keep In Mind
That’s a wrap! To sum up, the Agile approach is beneficial in product development because teams can always adjust to change. Skipping steps in the development process isn’t a good idea, as you can end up launching a poor-quality product. Most often, more members in the development team don’t translate into faster delivery.
Hopefully, these answers made it more clear on what building products means and how agile development teams work.
Key Things You Should Know When Transferring to A New Software Vendor 
Introduction to Atomic Transactions - How A Simple Database Operation Can Highly Impact Your Business