Skip links

Product Playbook

Solution Creation aka Prototyping

In the first 2 stages of your product discovery process you a) identified a pressing user problem and b) got a high-level picture of how your solution could look like.

Now it is time to build a proper prototype.


Before building the prototype, you should work on the following tasks first:

  • Decide which validation experiment(s) you want to run: In order for you to know which kind of prototype you need and in what detail, you first need clarity on the validation frameworks you want to use for validating your solution.
  • Check technical feasibility: Is it possible to build your solution? Involve your engineers in this discussion (ideally you already did so in the ideation phase).
  • Check legal feasibility: Are there any legal aspects that affect the implementation or launch of your solution?
  • Check expertise feasibility: Does your company have the right expertise for building and managing the solution?
  • Create user flows/wireframes
  • Create a customer journey

Build Prototype

Depending on the experiments you want to run with your prototype, a prototype can be a variety of things. Here are the most common ones:

  • Landing page: A simple website you lead traffic to can help you find out if your solution is attractive to your audience. Even if you plan to build a new SaaS product, a few “screenshots” of your tool are sufficient, you don’t need a full high-fidelity prototype yet.
  • Digital prototype: A digital prototype version is helpful to test the usability, desirability, and feasibility of any kind of digital product. This could be a click dummy your UX team builds with a tool like Figma. Or you as a product manager could build a fully functional prototype with No-Code or Low-Code tools. Depending on your use case the prototype could be a web or mobile app.
  • eCommerce solution / physical product: How a web store should look like and function, especially if you use out-of-the-box solutions like Shopify, is common knowledge today. However, there are 2 use cases you might want to prototype:
    • You can prototype whether you can build the shop functionalities and UX you want with existing solutions like Shopify (and using their apps/plugins), or require a custom-built solution from the beginning.
    • Another validation can focus on the physical product you want to sell in your store. For instance, you could validate your solution with the use of white-label products before producing your own brand and approach people “offline” (e.g. on the street) with your product. That way you have the great opportunity to collect instant feedback, and if positive you can later sell your own brand through an online store.
  • Backoffice validation: Sometimes you might not need any “real” prototype to validate your solution. For example, your sales team could offer your customers on the phone a “hypothetical future product” or cross-sell an affiliate product. If it resonates well you can consider building the actual product.
  • Paper-based prototype: A quick and simple way to show your solution to your users. Not suitable for collecting statistically significant quantitative data.

Prototyping should always be a lean way to validate your hypotheses.

Thus, only build a high-fidelity prototype if it is really needed for testing the hypotheses you want to answer before you have collected enough confidence/data to build the actual product.

A design sprint can be right especially if your solution is complex and requires expert input and lots of creativity. As introduced in the previous Ideation chapter, often a design sprint combines the ideation of new solutions with prototyping and testing the best solution all in one week.

No-Code Solutions

With the rise of No-Code (and Low-Code) tools it is easier than ever for anyone to build fully functional products fast without large tech investments.

In many cases, you can already build up the basic user flow of your solution with such tools and have a “fully functional prototype” ready within hours.

In the following, I will only use the term “No-Code” and with that associate No-Code as well as Low-Code tools, which are often overlapping and both enabling non-technical people to build products themselves without the need of engineers and the requirement to code.

A good definition of No-Code tools is the following:

“No-code” tools are software development platforms that allow even non-technical employees to build and deploy their own applications without writing a single line of code. These tools often feature a simple user interface with drag-and-drop features, letting you easily visualize the development process and define the underlying business logic.

To work with Low-Code applications, people may additionally need some degree of coding or developer support. A good example is WordPress which often requires some HTML/CSS/JavaScript skills to build the solution exactly how you want it.

There are more and more No-Code tools available to build fully functional products. Thus, product managers and UX/UI designers can build the product on their own without dedicated developer resources. This is great for first experiments or even MVPs. In case your prototype validation is successful, you might already have a fully functional MVP you can launch in the market right away and build on further.

Webshops can be easily set up with Shopify. WordPress is an old-time classic for building web applications, Webflow is the challenger. Tools like Bubble even allow you to build your own database and connect APIs on your own. With Zapier you can connect/integrate a variety of services easily.

Some HTML/CSS skills and familiarity with the tool are often needed to use it effectively.

I believe No-Code skills will become more important for product managers in the future, so get started today working with different tools and become a product builder!

Learn more about the No-Code landscape here.