Back to Blogs
Assembling an MVP from an Engineering Leadership Perspective
Share this Article

Assembling an MVP: The Dos and Don’ts from an Engineering Leadership Perspective

  • Publish Date: Posted over 1 year ago
  • Author:by Kris Jones, Director of Engineering at Nisos
Kris Jones, Director of Engineering at Nisos shares his advice on how you can launch an MVP for a new startup or team based on his own experience and success!

With over 10 years of experience in the industry and 5 years experience in top leadership positions, Kris Jones - Director of the Engineering team at Nisos - provides his expert insights and advice on how you can successful launch and navigate an MVP to benefit your business.

As an engineering leader, starting a brand new project can be exciting. A new greenfield project, whether it's started independently or with a team, presents a great opportunity to solve new and interesting problems, explore new areas of technology, and even correct the mistakes made in past projects.

With no definitive ‘right’ avenue to take, it can be very easy to lose focus on the main objectives and get caught up in irrelevant details. This is especially the case if this is one of the first greenfield projects you are leading.

Below are the key areas that I find vital to getting a project off the ground…

The Planning

Hours of planning will save you weeks of coding

Software development takes time, it is expensive and it is very easy to get trapped in a rabbit hole of irrelevance. I am sure a lot, if not all of us have been there at one point.

As an engineering leader, it is your responsibility to seek clarity from your leadership regarding the definitive problem that your engineered solution will solve. Especially in the early days of a project, it is key to understand the scope and main problem sets that are being addressed. From the MVP (Minimum Viable Product) to MMP (Minimum Marketable Product) releases, it is critical to have a clear set of goals and problems that your product will solve.

From your problem definition, it is key to plan architecture and outlines how certain pieces of functionality should be built. This should be stress tested with your team and scenarios played out to ensure you are building on solid foundations. At this point, it is vital to define and document functionality that is in and out of scope. Communicating this to stakeholders ensures that you maintain buy-in through the development journey.

From when a problem is defined by a product team or the business leaders and ideas around an MVP/MMP are starting to take shape, you should give yourself at least one sprint to spike out some of the potential larger issues and to start to plan out and test your planned architecture. This phase will allow you to understand some of the key challenges that the build will incur while de-risking certain aspects through research and throwaway PoCs.

Coming out of your planning phase, you as an engineering leader should be confident of the six-month plan, technology stack, and architecture. As the project grows and pivots these initial decisions may change but you should always start on a solid technology base.

Must Dos

After the all-important planning phase, it is your job as a leader to ensure the project and processes are in place to best ensure success. The following is a list of must-dos to ensure your project and team are the best set up to be a successful product delivery team.

Define the process: this is incredibly important to ensure your team remains focused and on track. The actual process itself shouldn’t matter, whether that is scrum, Kanban, etc, what is most important is that the process is clearly defined, followed by the team, and constantly reflected upon and refined so that the process works for your team. Your process should enable team-wide transparency, and inter-team communication and ensure there are no knowledge silos created as the project evolves. Your process should force best working practices and keep your team aligned on the short, and medium-term goals and of course keep releasing value top of mind.

Release cadence: this determines the frequency at which features are delivered to beta and production environments. As an engineering leader, you have control over the release cadence. The faster you can deliver features to beta and

Production environments: the faster you can receive vital feedback that will give your product the best chance for success. It is your responsibility to establish a healthy release cadence for both beta and production. A continuous beta release cadence helps stakeholders gain confidence in the technology and product being developed. It also provides them with an early preview of specific features and enables them to validate functionality against prior assumptions.

Establishing a good relationship with stakeholders: creating channels for two-way communication is crucial for the project's long-term success. If you can deliver to beta every two weeks, then a solid production release should be more manageable. Although production releases may be beyond your direct control, it is vital as an engineering leader to encourage your stakeholders to ship. There is nothing more important for a product than customer feedback.

Make sure security is a top priority: when defining your MVP or MMP, it may be necessary to walk back certain features and functionality until future releases. However, security cannot be compromised for your initial product launch. The risk of a data breach, compromised API routes, or exposure due to hacking is not worth the reputational risk to your product or company. Though great security may require specialised skill sets, it is your responsibility as an engineering leader to ensure that you have as many bases covered as possible. Security is a crucial aspect to consider during the planning phase of a project when defining the architecture. Identifying key entry points and possible exposures is a great first step in ensuring that your application is and remains secure. Some best practices include setting least first access permissions for iAM roles and user permissions, ensuring that no unauthenticated APIs can access user data, making sure that S3 (or similar buckets) are never accessible by the public, and ensuring that no API Keys or passwords are ever stored in code and that they are always kept within a secure store/vault.

Remain strategic: keep the long-term vision in mind when making key decisions about architecture, security, and automation. While it's important to focus on the present and ensure your team is building the right thing for the current release cycle, as the leader, you must also understand the long-term vision for the product and technology. This understanding should inform longer-term architectural decisions, help you identify the talent you may need to bring onto the team to achieve product goals and research third-party vendors and tools to help your product stay ahead.

Get the balance right: engineering leaders must strike a balance between being tactical and strategic. In the early days of a project, it's more likely that you'll need to be more tactical, but as the project and processes mature, it's important to take on a more strategic role.

Pitfalls to be aware of

With the must-dos of starting a new project, there come pitfalls to look out for. There are a whole host of potential pitfalls you need to look out for as a leader but the following two are the two most common that I have personally experienced in an attempt to derail a project's progress.

The dreaded HiPPOs: also known asThe Highest Paid Persons Opinion. This is when a CEO, VP of Sales, or COO comes wading in to completely change the roadmap on a whim, with no respect for the process or and in most cases no actual thought behind their great idea. I would be shocked if you are an engineering leader and haven’t yet experienced this. The best piece of advice I have to deal with HiPPOs is to address it at the start and throughout the project.

Communicate and be transparent about the roadmap, the why behind features, and the thought process that needs to be into defining a feature before it can go into development. This will arm you with what you need when the HiPPO arrives at your door with the next great feature request. Yes you will have to have difficult conversations, and yes maybe their idea is the next great feature and it should disrupt the roadmap. What is key is that everyone respects the process and understands the why behind the current priorities. I have always found this helps HiPPOs feel a part of the process and that their ideas are heard so they are not disheartened by you as an engineering leader ‘just saying no’ to them.

Over-engineering: as engineers, we all love building shiny, new things that use the latest and greatest technology. However, as the leader, it's your job to ensure that you choose the right tech stack for the job. Keeping your team focused on the right deliverables, being clear about task expectations, and preventing scope creep from turning into over-engineering are tough skills to master. You don't want to plan the implementation of every task down to the smallest detail, but you do want to ensure that your team has enough autonomy. This needs to be balanced with the value vs. effort paradigm. Does the effort match the value that a particular implementation will bring to the team?

In my experience, the best way to handle over-engineering is to ensure that there is a lot of communication among the team members for every task. Explain and question the value vs. effort of proposed solutions. This approach may vary from team to team and from engineer to engineer, but I strongly believe that it's crucial to get it right, especially in the early stages of a project.


Finally, it's crucial to focus on continuous delivery. By delivering small, incremental improvements on a regular basis, you'll be able to keep the project moving forward and make sure that it stays aligned with the needs of stakeholders and end-users. This iterative approach will also help you identify and address any issues early on, before they become major problems.

Overall, leading a high-performing engineering and product delivery team requires a combination of strong leadership skills, effective communication, careful planning, and a focus on continuous delivery. By keeping these key factors in mind, you'll be well on your way to success.

Looking for your next career move in technology? View all our live IT roles HERE!

Our team of specialised IT consultants can help with everything from interview tips to CV advice and landing your dream job! Do not hesitate to get in touch today at or send your CV to

Keep up to date with all our latest blogs​, tips, advice and news HERE!​