Always Be Prototyping - Interview with Oskar Kwitek, Product Strategist at Boldare

Matt: Welcome to Around Product Development, our weekly show featuring lively 25-minute discussions on hot topics in digital product creation. We cover everything from monetization to innovation, providing actionable insights from digital product practitioners and creators in the Agile Product Builders community, powered by Boldare. This week’s event, “Always Be Prototyping,” features Oskar Kwitek, a product manager and strategist at Boldare. We’ll learn how prototyping can mitigate product risk and why it’s often misunderstood. I’ve also heard that Oskar was a skipper in his past life, which I’m curious about. Oskar, welcome to our webinar. Could you introduce yourself and share a bit about your background?

Oskar: Thank you, Matt. Very happy to be here with you today. Prototyping is 100% aligned with our tight schedule today, so I’ll try my best to share hands-on experience, tools, and approaches to get the most out of prototyping or POC (proof of concept). As for the skipper part, yes, there’s always a point in your career where you just want to leave it all and explore the ocean, forest, or mountains. For me, it was the ocean, 100%. I’ve been a professional skipper for a while, doing Mediterranean and Caribbean cruises, mostly with friends. I believe the Agile Product Builders community is like a friend you can share your ideas with. I’d recommend myself as your skipper next time you go sailing.

Matt: Thank you so much. So, Oskar, we’re talking about prototyping today. Can you tell me your understanding of prototyping? My understanding is that we start with prototyping to build a product and then move on to other stages of product development. Is that right? Can you explain what prototyping is exactly?

Oskar: Definitely, Matt, you’re 100% right. This is about testing, about sketching out your ideas before committing to the final design, project, product, whatever it is. From my perspective, the prototype or prototyping process is a tool you use to validate assumptions, ideas, and experiments, to start working on a tangible version of your product or idea. It doesn’t need to be the product; it could be just an approach or process. We can use prototypes in various contexts and scenarios. After prototyping, there’s usually testing, validation of the experimentation process, refinement, and possibly another prototype as we get closer to the final goal. Or, we might decide to start from scratch again. So, prototyping is continuous discovery, very connected to the product development or delivery process.

You might be also interested in the article:

The first version of your app: Prototype or MVP?

Matt: And did I understand it right, that product development and prototyping are related? For me, prototyping is like a car—you have an early prototype that doesn’t drive well, but it shows potential. Then you move on to product development. I can imagine digital products having prototypes, but did I get it right that you can also prototype ideas, thoughts, or processes? That’s new to me, so I’m not sure how that works.

Oskar: Definitely. Whenever you start creating a car or designing something, you want to ensure you’re on the same page with the audience you’re providing this product or service for. The lean startup approach says fail fast and learn quickly to mitigate bigger risks. You can always align with whatever you do. So, let’s start with this: whether it’s a process, product, or service, there are four risks you need to mitigate or validate to create a successful approach. First, desirability—does the market want your feature, process, or product? Next, feasibility—can you actually make it? Do you have the team skills, and does the technology allow it? Then there’s the money factor, or viability—will you make money on it? Does it come with profit? Sometimes we think about new features that would improve user experience or the overall product, but where’s the business behind it? Lastly, usability - will users figure out how to use this feature, product, or process? Will it be self-explanatory, or will they need help? You can validate everything along the way, and you should, to make it as effective as possible with the resources you have.

Matt: And to make sure there’s less risk. So that’s one of the big reasons to prototype, right? We prototype to understand the risks and avoid them.

Oskar: Definitely, exactly.

Matt: So, it’s a process we start at the beginning, right? Does it come back a few times as well? Is it something we do only once or in multiple phases? I read an article about prototyping being a constant process, but I can’t imagine how that works. For me, we start with a prototype, then it’s gone, and we move forward. But the article said it can return in multiple stages.

Oskar: So basically, this is one of the biggest mistakes or misunderstandings about prototyping. As I said at the very beginning, prototyping is a tool you use at every stage of product development. It’s not a one-time activity or a one-stop shop. You don’t just create a prototype, validate the idea, and move on. In our dynamic environments, prototyping is essential for thriving, not just surviving. I use prototypes almost every day. It’s not just about the prototype itself; it’s about what you want to validate, how you plan your experimentation process, your assumptions, your clients’ assumptions, or other stakeholders’ assumptions. You also need to consider market trends and check if they’ll work in your case. With the dynamic presence of AI and other tools, you need to validate whether new approaches will work for you. Prototyping is a whole process. It starts with strategy and the process of experimentation and assumptions, prioritizing them from the riskiest to the most confident, and validating them as the most appropriate approach to mitigate risks at all costs.

Matt: So, Oskar, if I’m honest, prototyping seems like something we start at the beginning, but it can be used through all stages. Doesn’t it become very costly and time-consuming if we need to prototype all the time? Maybe it’s easier if it’s internal, but if you hire a company, doesn’t it get expensive quickly? As a business owner, I’m curious if it gives an ROI. Is it efficient in the end? Does it give something back?

Oskar: Yeah, it is. The third question I usually come across at some point in our projects, because whenever you start doing the development process, there is always, let’s say, this gray area. If we’re supposed to plan ahead, there are some major fires that are supposed to be put out first. But definitely, in terms of prototyping, it is a cost generator. You can’t say it doesn’t generate costs because you need to sit down and create a strategy, get to know your users, create personas, conduct interviews, etc., to better understand their needs. You need to create assumptions and experiments, plan them, and make the processes.

So it does generate cost, but if you think about lean strategy, lean approach, and failing fast, learning faster than your competitors, you don’t want to wake up one day developing the whole product, putting a lot of money into it, and then realizing that it doesn’t create the engagement you wanted or meet the objectives you had initially. Or there could be a new market trend that changes the landscape completely, and you need to start from scratch. I’ve had such experiences in my past career, so I don’t like them. If you’re satisfied with your prototype, if you’re proud of it, you’ve probably put too much effort into it. You’re supposed to be a bit ashamed of your prototypes. Validate whatever comes to your mind because it’s all assumptions—your assumptions, your customers’ assumptions, or your business owner’s assumptions—not validated by the market.

That’s what prototyping is about: validating quickly and reducing costs.

It’s always about cost, but comparing the cost of changes later on makes a huge difference.

Matt: So it’s about long-term thinking versus short-term thinking, right? Long-term ROI, efficiency, and cost savings versus short-term cost savings. But my follow-up question is, if I need prototyping to develop a product, what does it cost? Are we talking about a couple of thousand euros or dollars, tens of thousands, or even hundreds of thousands? I have no idea. Could you clarify this for business owners?

Oskar: From my perspective, this could be 100% free. There are a lot of free trials for major tools you can use on the internet. We can do what we call “mashups,” combining different tools to provide the full experience. Based on a 10, 20, or 30-day trial, you can validate some of your ideas and reduce costs to the very minimum—just your effort and time. But it depends on the feature, product, and complexity. I would say it’s always cheaper than developing the actual feature, testing it, and then changing it completely, which takes time and effort from the team, planning, and design. There are many interconnected aspects within product development. I’m not even talking about the technology or data you can gather. So, it’s completely different.

Matt: For the curious people, it can range anywhere between zero and whatever you want, right? So it can probably go very far.

Oskar: But let’s try to focus closer to the zero end rather than spending a lot of money. Prototypes are supposed to be cheap, fast, and very, very effective in terms of validation. This isn’t about creating something to be proud of; it’s about making sure that whenever you invest money later on, it’s going to pay back.

Matt: Yeah, well, very nice approach. It makes sense, right? As a business owner, you don’t want to spend a ton of money. It makes sense to be frugal. So, that’s good. When it comes to prototyping, is there a specific approach or strategy to follow, or is it more free-form? With your years of experience, is there a logical process or fundamental steps to follow?

Oskar: Right. So I use different terms throughout our conversation, like hypothesis, assumption, and experiment. You want to ensure that your prototyping process is very rigid and strict in how it’s conducted. Testing too many things at the same time can generate more cost and effort than needed to validate some ideas and assumptions. You need a validation plan. When mapping your assumptions and ideas, it starts with the idea. For example, if I say my product needs to have a feature, I need to ensure it brings value to a specific group of customers. This can be validated through an analytical tool, and based on the results, whether positive or negative, I act accordingly.

This is a crucial step. If the validation of the prototype is negative, it’s not necessarily a failure. Success is both negative and positive because you learn something along the way. However, many people stick to the idea or don’t believe the customer feedback. This is a common mistake in handling prototypes. You need a rigid, structured process. From a strategic point of view, consider what ideas come to your pool of assumptions and who the givers are—stakeholders, market trends, or competitors. Prioritize them using different techniques and validate them through interviews, campaigns, pre-sales, simulations, or whatever is most suited to your case.

Matt: And Oskar, you mentioned how the process should work, right? It’s easy to make some mistakes. We have only five more minutes left, so I want to ask you two more questions. Are there any risks in prototyping? Is there a downside that we maybe don’t see? I honestly can’t imagine any, but I’m sure you’ve encountered some in your career. So, are there any risks we’re taking? Is there something we should be aware of?

Oskar: This depends on, let’s say, the business sectors. In very formal environments, for example, banking and finance, where there’s a regulatory layer, it’s sometimes very hard to create those effective prototypes. I was working with one bank that showed me a prototype that had 1 million lines of code, which was almost a full product that could be released easily to the customers but was never actually validated if it was good or not. So, it depends on the environment. But I would just reiterate that the most common mistakes in prototyping are getting too attached to your initial idea, ignoring user feedback, not actually working on the user feedback you collect along the way, and 100% overcomplicating the prototypes.

You might be also interested in the article:

Proof of concept, prototype, MVP - how best to validate your product idea?

Matt: But maybe it’s more of a problem with the companies or the process rather than the prototyping itself. Right? Let’s not blame prototyping in this case.

Oskar: Right, exactly. As I said, a prototype is a tool that you use in a very specific way. Of course, it needs to have the background of the company you do the prototype in. But definitely, it’s just a tool. It can be misused easily like any other tool.

Matt: Yeah. And maybe to give our audience some practical tips. What are some tools, websites, and resources they should look at when getting into prototyping, or even if they already know a little about it? Where can they start, and what’s interesting to you? Where do you look?

Oskar: Definitely. So my prototyping Bible has always been “Testing Business Ideas“ by Strategizer. It’s a great source of knowledge on prototyping techniques, experimentation, and why we do it. I would start with this one. Then you have a variety of tools you can use, like Lyssna, Proto.io, Figma, Canva, Sketch, and Envision. There are so many available on the market right now. I’ll try to link them later on in our Slack channel to make it easier for you to navigate and to give you some tips on which circumstances they’re best suited for. But definitely, if you don’t have any idea about prototyping, “Testing Business Ideas“ by Strategizer is the go-to resource.

Matt: Yeah, but there are lots of resources available online if people search for them, right?

Oskar: 100%.

Matt: Let me check for a second. I think there’s a question from the audience. Let’s see if I can still answer it or see it. Yeah, the question is: “How do you prepare a SaaS prototype to check if a user is ready to pay for it? They always love the product while using it, but when it comes to the ready product, they’re like, ‘nah, I’m not going to pay for this.’ Is mocking the pay button a solution? Won’t the user be frustrated?” And if you can keep it short, Oskar, so we don’t go too far over 25 minutes.

Oskar: Yeah, so not going through the context of it, but definitely, the pay button or sign-on button is the way to go. Just make sure that your users know what’s coming next. So if there is a pay button, there should be some models and pop-ups with information that you’re working on this feature, marketplace, or SaaS product of yours, and that it will be available in some time. It’s going to bring them value or whatever. For example, you could have users sign up as early adopters to test it later on, right? So, definitely the best proof you can get is taking the leads and seeing if users are willing to try and pay for it. If they are, you’re good. The pay button or sign-on button, whenever it makes users convert in the way you want, is a very effective way of validating.

Matt: All right, Oskar, thank you for our lovely talk today. It was a pleasure. Very interesting. I would say you’ve taken us on an interesting boat ride across the prototyping lake or sea. As a true skipper, it was nice to navigate with you. So thank you once more, from me and the audience. For the audience, you’re very welcome to join the Agile Product Builders community. The link will be shared so you can click and join.

Next week, I’d like to invite you to a talk with Agile coach Todd Langford. He’ll discuss what leaders can do to get short-term improvements from their teams, which I think everyone is interested in. We all want improvements, we all want them short-term, and we’re all working in teams. So, see you next Monday at 03:00 PM CET. Oskar, thank you again. It was a pleasure talking to you. And for the rest of you, have a very nice day. See you next week. Thank you.