Releasing a new product or service to the market is risky. Lean approach to product development can mitigate that risk by releasing often, testing with real users and applying the results to your product, allowing you to find the product-market fit. Find out how we created Boldare leveraging lean startup thinking.
Product Design and Development, Poland
Anna Zarudzka, CEO, Chilid
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.
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.
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:
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 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:
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.
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:
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:
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.
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.
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.
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.
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:
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.
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.
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.
Piotr Majchrzak, CEO, XSolve & Anna Zarudzka, CEO, Chilid
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.