As a full-service product development company, we handle different types of projects. Some are ideas just taking technological shape in the form of an MVP, others are established apps looking to re-write their legacy code to fulfill new business needs.
For clients looking to build an MVP, we sometimes start with a technological proof of concept, or a prototype, to validate the parameters of the business idea and how it would translate into a digital product.
For most projects, we start with a product discovery workshop, which gives us the scope and way of working to kick-off the new business relationship.
In this curated list of topics, you'll find the full flow of signing a new client and kicking off a new software development project.
Nine years ago, we were using a forefather of Invision that enabled us to show multiple screens to our clients. We called it a clickable prototype because you would click on select places on a screen to prompt another one to open.
Then we moved on to the functional prototype, with more or less the same design. We would implement the frontend and make it possible to interact with visual elements in a dynamic way, without any actual functionality. These were some very convincing tools for clients in the proposal stage because they would offer a glimpse into how a product could look like.
By 2017, we perfected the functional prototype so much so that we offered clients a satisfaction guarantee - we would build the prototype in four weeks based on their specifications and if they liked the outcome they would pay for it and continue working with us.
Every proof of concept is different but some of the steps are pretty much the same. When building a prototype, we get to ask ourselves a lot of questions along the way. This type of exercise brings issues of scalability and which tools we should use, and this is very important information to get before starting a long term project.
The first step is the selection of 1 or 2 of our most experienced developers.
After reviewing the proposal, they consult the account manager to confirm the most valuable things to include for the main flow of the prototype.
We also work on a list of “WoW” factor items, some key details, and functionalities that can better reflect our capabilities. They can be key details like aligning elements, adding the client’s logo and beautiful design to create a demo that would exceed expectations.
Another important part of our process is Ivory, our development acceleration framework. Using AWS managed services, Ivory enabled us to automate common functionalities and move twice as fast.
This is a very fast process, happening over the course of two weeks or less.
We have daily syncs to eliminate any kind of dead time and we make sure to test everything as we go.
Once the prototype is ready, we organize a rehearsal demo or two before we present it to the client.
During the official demo, we align expectations and the vague images in our heads. Both the team and the client gain a better understanding of how the product is meant to look and to function. This is something that usually takes a long time and many, many discussions down the road. We would always start with a proof of concept if possible.
Discovery workshops are a great way to establish the parameters of a new collaboration. We’ve been doing them since 2017, on-premise, with the focused goal of understanding a potential client’s needs.
A first preparation is in selecting the team who will attend the workshop. Experience, skills, and availability all factor in this decision.
After that, we do initial research into the company, their product/service, and the market they’re operating in, sometimes peeking into some competitors as well.
With the team ready and some key information listed, we prepare for a one to two days intense workshop where we try to get everyone to focus on the matter at hand. For our team, this means minimizing all interruptions and other tasks for the duration of the workshop.
The workshop is run by a small team on our side, which usually consists of a project manager, a senior developer who will move on to become team leader, and a designer. In some workshops, we also have our sales representative join in.
On the client’s side, we usually welcome a product owner who has the authority to make decisions regarding the future of the product or service. On different occasions, we were joined by more than one person, a company manager, a product owner, or a technology officer.
We found that having fewer rather than more people makes for a better meeting in terms of information flow, decision making, and time management.
At the beginning of the workshop, we usually take a few minutes to introduce ourselves and set the terms of the discussion.
Gathering expectations right from the start allows for a focused workshop and makes it easier to determine the success of the workshop once it’s over.
Everyone is invited to list their expectations regarding the content and the format of the workshop. That includes a list of items they expect to discuss, the outcomes they hope to obtain, and how they expect the agenda to unfold.
Going into the product/service itself, the main goal for this part of the agenda is to understand the needs of the client and the exact problems that they are trying to solve with it.
Some key elements of this discussion include the product/service vision, the targeted customer segments, buyer personas, market positioning, competitors, key partners and integrations, as well as a desired product/service evolution over time. Together with the client, we create a business model canvas for their product/service.
While some of these elements are more clearly defined than others, our goal is to mostly listen and try to understand. Active listening, we found, is essential to this entire workshop. This allows us to explore each of those key elements without jumping to conclusions and without swaying the conversation, which enables us to identify the real issues the client wants solving.
For this stage, we work together on identifying the main user roles for the platform or app. Then we map each user’s journey and establish high-level details such as order of priority or essential functionalities.
Mapping the high-level features identified on the user journeys sets the ground for a later step which is determining what an MVP should include.
In this section, we look at the systems required to build the product/service and what type of tech solutions would be best suited. This includes:
With a list of functionalities created, we now need to determine which of these should be a part of the MVP.
After analyzing the complexity and risk for every feature, we agree on a list of core functionalities needed to create an MVP.
Many clients are visual, which makes this section essential to gaining a common understanding of what the product/service should look like and how it should function.
Our UX designer creates a series of wireframes based on user flows, which we then explore together.
Similar to setting expectations, defining a way of working early on enables more efficient communication. This is a key step in creating a united team that can deliver well together, with members from our side and the client’s side. The client will be a part of the team, not just a stakeholder who gets reports from time to time.
In this final part of the workshop, we present to the client our processes, roles, and responsibilities. For example, the role of product owner is usually represented on the client side. Being as this is a strategic role, we make sure that our process includes daily syncs between the team and the product owner. If there will be a development team on the client’s side as well, we define the terms of the collaboration between their team and ours.
Some of the essential issues discussed in this section of the agenda include how teams are organized, our usage of Agile practices, accountabilities, as well as definition of ready and definition of done, each with its own acceptance criteria.
Another key issue is listing the decision-maker for each topic. In some cases, clients will tend to use a decision-by-committee system which can lead to a lack of clarity or the lack of actual decisions. Using some of our own internal processes, we help facilitate the designation of decision-makers which helps move things along faster and minimizes the risk of having to overturn a future decision or even future work.
Before any activity will begin on a project, every project requires an estimate for the completion time. This helps both us and the client understand and control better the effort and budget aspects of the project.
This is why being as accurate as possible is important. But estimates, by their definition, cannot be 100% accurate and represent just an approximate calculation which we do in different stages of the project.
Depending on the stage of the project and the information we know at that point, the degree of confidence that we attach to our estimates can be bigger or smaller and can be represented on the Cone of Uncertainty.
But it’s important to note that estimates do not represent delivery guarantees and while we strive to deliver on the set deadlines, the nature of software development projects is unpredictable.
The key people in the estimation process are the Head of Engineering, Head of Delivery, and the account manager from Sales.
We use the request for a proposal that the client drafted to identify the declared scope of the project. Based on this high-level scope, we create a plan f how we think we can achieve it.
Similar to the process for building a proof of concept, we identify the right people for the job in terms of skills and availability. This can include developers, a project manager, a designer, a quality analyst etc.
During an estimation session with the team, we use the PERT technique, which uses a weighted average of three numbers to come up with a final estimate. The resulting PERT estimate is calculated as (O + 4M + P)/6. This is called a "weighted average" since the most likely estimate is weighted four times as much as the other two values. Combined with the cone of uncertainty, the technique allows us to extract an estimated interval from a best-case scenario to a worst-case scenario. We also determine an optimal delivery time or project duration based on this.
During the development phase, we apply the SCRUM methodology, by working in sprints of two weeks (10 days) towards the complete implementation of the product.
The number of sprints depends on complexity, effort, and team composition.
At the beginning of each sprint, we plan together with the client the content that will be delivered.
At the end of each sprint, we present the new functionalities implemented and deliver the working software so the Client can already test it.
During the sprint, the team ensures that the developers have enough content ready to develop the next sprint, in order to increase the team’s efficiency.
Usually, the team analyses the upcoming user stories in the light of what was already implemented and re-estimates them, if needed, having a better knowledge of the expected complexity and effort.
In product development, the minimum viable product (MVP) is a product with just enough features to gather validated learning about the product and its continued development.
An MVP contains the bare minimum set of essential features and functions required to be released to a group of early adopters/customers who will use the product and provide honest and valuable feedback.
Gathering insights from an MVP is often less expensive than developing a product with more features, which increase costs and risk if the product fails, for example, due to incorrect assumptions.
Every project comes with its own flow. If we were to summarize some general guidelines, these would be it.
Generally, we're looking at a timeline of 3 to 6 months to build an MVP for our clients. This timeline is strongly influenced by the complexity of the project and the scope changes that occur during the implementation.
As a team composition, we usually assign a team of two to five developers, one designer, one project manager, and one quality analyst.
BEYOND THE STANDARD NDA
We implement standard security practices on multiple levels, which have successfully passed 3rd party security audits. We're proud to say that in the 10 years we’ve been in business we’ve never had any security incident.
At a project level, we make sure that all content is stored on cloud-based solutions, with audit logs and 2-step authentication. Internet traffic is handled through VPNs if the context requires it.
At a company-wide level, access and permissions to cloud tools are reviewed quarterly in a formal process. We also have standard onboarding and offboarding procedures that handle access to data and tools immediately. The software solutions we’re using are enterprise-level, with the corresponding secure implementations.
Our policy is to use a limited number of 3rd party solutions, in order to have constant awareness over the data we're handling and creating.
For our physical office, we've implemented a WI-FI network segregation for employees and visitors with traffic being routed through an in-office firewall.
The standard employee NDA is constantly reviewed to ensure that it's up to date with any new or improved security methods according to industry standards.
Regarding GDPR, we traditionally had only a very limited number of cases in which we operate the production environment of the client.
With AWS we segregate Dev-Staging-Prod at an account level and there is audited and restricted access to Production. This means in practice we almost never see the live customer data.