How to test a business idea with minimum cost, time and effort

The companies

XSolve and Chilid are sister companies, working under one roof since 2010. On their home turf in Poland, they have grown to become influential in the tech industry, pushing innovative, agile-driven software development and human-centered product design for their international clients.

Both XSolve and Chilid also have a history of supporting digital transformation, aligning product strategies and development processes so the products they released could grow sustainably with their users.

Working with giants such as Bla Bla Car, Corel and Bosch, the companies have collaborated on over 100 products together, building web and mobile apps, e-commerce platforms, and SaaS software across variety of industries including automotive, travel, energy and consumer goods.

Problem: Is the target group ready for the business proposition?

Eight years ago, the market wasn’t ready for an all-in-one product development company with product designers and software devs working in the same team. But client needs have evolved. Increasingly, there is a global demand for trusted software development partners who can develop a product from a prototype to a scalable app with a holistic approach that includes supporting the client’s digital transformation process.

The founders of XSolve and Chilid responded to this evolution by creating Boldare, a completely new brand combining the power of both companies. However, given that 40% of new ventures fail due to a lack of product-market fit, they decided to test their business hypothesis before going all in. They needed solid data that would validate or contradict the idea behind the new service.

Solution: Lean startup approach and a cross-functional product team

Having worked with digital products for over a decade, the CEOs decided to adopt a lean startup approach as a cost-effective method of delivering products that the market and target group actually wants. Fundamental to this approach was a broad mix of skilled, experienced people, forming a cross-functional team that could:

• deliver the MVP to market
• test it on real users
• collect valuable data
• draw meaningful conclusions to inform future decisions

The principles of lean product development

Lean product development relies on cycles of Build-Measure-Learn, progressing until you achieve a product-market fit, the stage where your product is desired by the users. After reaching a point where your product is saleable, you are ready to scale it. At every stage of the full product development cycle (prototype, MVP, product-market fit, scaling) versions are released quickly and tested with users to get data and feedback. That data is then used to make product improvements or pivot (change the direction of the development).

The cross-functional product team

The other crucial factor in achieving success was creating a product team with all the right skills. The CEO of Chilid, Anna Zarudzka, became the Product Owner. She selected the team members, looking for competencies in these key areas:

• Brand (Brand Strategist),
• Product Design (Interaction Designer, UX Designer, Graphic Designer),
• Software Development (Frontend Developers, Growth Engineer),
• Content (Content Strategist, Content Writer),
• Research (Qualitative and Quantitative Researcher).

Finally, the team needed a Scrum Master to look after the process. The core team members had worked together in the past and this would help the the team achieve high-performance quickly.

Product Discovery: Using the Business Model Canvas method to help define business goals, and a Product Canvas to fulfill them

The entire Boldare team, together with the Product Owner, kicked off the development with a Product Discovery workshop. The workshop was critical for aligning the team with the business goals and providing strategic guidance during the development. They used two main techniques:

1. Business Model Canvas - this was used to map out the business goals from high-level (e.g. mission, vision, value proposition) to low-level (e.g. ideal customer profile, ideal offering). To achieve these goals the team needed to validate one hypothesis: “The client is choosing a product development company over a software development company.”
2. Product Canvas - this supported the team in defining how the product can realize the business strategy as defined by the Business Model Canvas. The Product Canvas helps to design a better user experience and select the right features to fulfil the business goals and satisfy user needs.

Using mood boards for early testing

From the beginning, the agreed rule was that every aspect of the Boldare brand proposition should be tested with real users and every decision supported by real data. The Boldare team looked for every opportunity to gather real feedback and information from the target group.

For the first test, they used website mood boards. A mood board is a collage of images, colours, fonts, and iconography that will inspire and guide the design of the website, a quick glance at the website’s look and feel.

Two mood boards were selected for testing with the target group, using a survey and focus group to measure how closely each mood board would be associated with the desired brand identity and values. A ‘winner’ was chosen but a number of potential improvements were also identified:

• make it LESS COLD
• make it LESS OLD-SCHOOL
• make it much more OPTIMISTIC
• make it more SMART
• make it more LIKEABLE

Additionally, using a variety of cognitive psychology methods, the team identified the language used by the target group to describe product development problems. Surprisingly, the vocabulary in use was related more to software than products and further tests were needed to validate the business proposition.

Building an MVP: from mood boards to website in 4 weeks

With an experienced Product Owner on board, clear business goals for the website, and a well-prioritized backlog, the team got to work. The product was delivered iteratively within the scrum framework with a working increment of the website delivered in weekly sprints.

Technology to fit the business goals

It was important that the frontend technology fit the business goals, enabling production of an MVP ready for testing in 4 weeks. To fulfil this goal, the team had to take several factors into consideration. Firstly, the coding had to be quick and easy. Secondly, the content writers had to be able to upload content and images in the CMS, enabling them to make changes right up to the last minute. Finally, the website needed to load quickly around the globe, giving target users from different countries a first class experience.

The obvious tool might have been WordPress, however the frontend developers decided to move away from this popular CMS due to problems with speed, scalability, security and general usability. They chose Netlify instead. Netlify is the latest all-in-one solution for building, deploying and managing web projects. It allows developers to plug-and-code at any time without complex configuration. Netlify also offers an open source CMS which is quick and easy to configure and allowed non-technical team members direct access to content editing. The chosen frontend methodology included Javascript, reusable APIs and Markup, meaning the site doesn’t need to run server-side code and is quicker than on WordPress.

Visual language for the website

Following testing and feedback, the second mood board iteration included the beginnings of a visual language for the website - a set of rules and reusable components to make the design process quicker and simpler and speed up the coding - particularly important in products with very limited timeframes. These elements would later become a part of the Boldare.com brand book.

Design Sprints 2.0

To achieve greater cohesion between development, design and content as well as save on time the team used a mix of two methods: design sprints and design thinking. They called it Design Sprints 2.0:

1. The team (designers, developers and content writers) gathers together for a wireframing meeting.
2. The aims of the sections and content elements of the website (usually provided by the Product Owner) are recorded on sticky notes.
3. The sticky notes are placed on an A0 sheet, first the aims of the sections then the content elements of each section. Within 2-4 hours, this usually produces the desired information architecture and a rough wireframe.
4. The Product Owner is consulted.
5. Once a consensus is agreed, the developers can start coding (straight from the sheet of paper), the designers get cracking with the UX and visual elements (based on earlier mood boards), and the content writers can work on content.
6. The increment delivered is not perfect but can be iteratively improved in future sprints.

This method allows the team to deliver large chunks of product in 1 week sprints rather than deliver everything at the end of four weeks of work.

Validating the business proposition with an A/B test

While working on the MVP, the team was simultaneously working on the research. The research methodology would determine the scope of the development work meaning decisions regarding testing had to be be taken quite early in the process.

Firstly, the team sat down together with the Product Owner to discuss what exactly they wanted to test and how they would be able to validate using both qualitative and quantitative methods. The group determined that in order to test, “The client is choosing a product development company over a software development company” hypothesis they needed to build two versions of the website: one for “Boldare, a product development company”, and one for “Boldare, a software development company”. Each version would have slightly different services and use subtly varied visual and written messaging to communicate the offering.

Secondly, the the main hypothesis was divided into five sub-hypotheses. Each sub-hypothesis had certain metrics and criteria that would later help the team determine whether the statement is true or false. Facilitated 1-to-1 scripted interviews with the target group were chosen to gather data to test the hypotheses.

Following the release of the MVP in product and software versions, all team members took part in conducting the interviews. The interviews were held remotely via Zoom and recorded for further analysis.

Results: informed decision-making and crucial feedback

The data gathered during the A/B tests turned out to be critical to the business decision-making process. The team were able to re-watch the recorded interviews and develop a backlog of improvements based on genuine feedback and user observations.

With ambivalent results for the first two hypotheses, it was clear that going with the Product offer is safe enough to try. Conclusions from hypothesis 3, 4 and 5 also allowed the team to set clear goals for the next release: the product version of the website needed to be clearer and draw from the simple communication of the software version.

Instead of spending a resource-heavy 4 months developing a full version of the product for the market, the lean approach allowed the team to release iterations quickly, test them with users, and gather crucial feedback to test the hypothesis, all within a span of 4 weeks.

The team is now working on a second release, which will launch the product to a selected group of users for further testing.