What’s great about quantitative experiments for us product folks is that on top of assessing the value risk of a product or feature we get insights on acquisition metrics (basically for free). It may therefore be tempting to put some additional effort into testing different ads at the same time as testing our product.

In this post, I argue why I think it’s important to at least keep things mentally separate in early stages of product validation. I will explain that

• conversion is the more important metric for testing value,
• reducing complexity leads to results which are easier to interpret and
• focusing on one hypothesis optimizes € to data and hours to data.

Sounds good? Let’s dive in!

Regard Clicks As Given

When testing value risk e.g. through a Fake Door MVP with your typical traffic acquisition through e.g. paid ads, users usually need to perform 2 actions:

1. Clicking on the ad to get to the landing page, if interested, and
2. giving the commitment by signing up, indicating interest, paying upfront… you name it.

A good performing ad with a good CTR usually indicates that it communicates the idea and its value very well and convincingly. A lot of signups on the other hand are indicative that people are convinced that the value of the service is higher than the costs imposed by giving the commitment.

The key messages of the ad can be highly aligned with those of the landing page–and of course they can be totally misaligned. If it’s overpromising or generic, chances are that CTR is high and conversions are low. If it’s poorly designed or not fitting your target group but leads to a convincing landing page for those who eventually get there, CTR may be low while conversions are stellar.

The point is: The ad and the landing page are different things altogether. And in the end, no matter how bad your ad performs, if those users are signing up in troves because your product hits a nerve, that’s a good sign! And it possibly just means that the ad sucks.

That’s why out of those 2 actions mentioned above, the second one is the one that’s meaningful for assessing value risk. And this action is measured by conversions rather than clicks. Which leads me to treating these aspects as separate areas of concerns and ultimately treating the CTR as given when interpreting the experiments’ results.

It’s Easy To Get Overwhelmed By Data

In a scenario where there are a lot of different ads running in parallel, leading to different versions of the landing page, there’s simply a lot going on. Finding out the causalities between all of these different factors often leads to not only complexity (and a longer time to get the setup working) but also to uncertainty.

Quantitative experiments already have a fair amount of degrees of freedom. In fact, they’re often a big bet on a certain set of product qualities (features, pricing, business model etc.). In such a situation, it helps to reduce complexity as much as possible, e.g. by varying only one aspect of the experiment at a time. To leave the acquisition channel out of the equation aids this goal.

So rather than A/B testing a lot of different ads, it may make sense to keep those constant to keep track of causal relations.

Splitting Your Budget And Attention

With every additional test you run in parallel, the absolute amount of visitors for each variant decreases when the budget stays the same. Pretotypes are designed to provide insights fast and with 10–100€. This budget spent on ads regularly buys something between 20 and 80 clicks. This is already low in statistical terms, so additionally testing different variants of a landing page will split users to a point where randomness clouds all insights.

For ads, this is slightly different, but to a point still holds true: There may be slight indications that one ad performs better than the other even on a small amount of clicks. And yet, setting this up means a lot more time spent on creating the ad/page variants, increasing the time to actual data.

Focus Pocus

With these three aspects in mind, I feel like rather than increasing complexity, increasing the amount of iterations instead is where the magic comes from. This means keeping as many aspects as possible constant and only changing those to be tested. It definitely helps to have a clear hypothesis for each experiment, e.g. by using Strategyzer’s Test Cards.

And while the insights regarding acquisition are useful, they should be treated as a by-product in early product validation. But if all goes well, the time will eventually come where acquisition is the more pressing problem. Until then, keep it simple and stupid.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

This is part 3 of my 12 Businesses In 12 Months series and this time it seems we hit something. I originally hesitated to use the standard Fake Door MVP with paid Facebook ads for validating B2B ideas, but this turned out better than expected. In this post I will

• explain what the idea was,
• the decisions we made
• and assess what I learned.

Here goes!

The Idea: Texts for Real Estate Agents with a Single Click

The product I had in mind was simple: Every real estate agent creates exposés for the properties they currently market. Texts that explain the surroundings and infrastructure nearby are always a part of that document. These texts are both very similar in structure and yet differ in the data from property to property.

The data is mostly retrievable through Open Street Maps and real estate agents already outsource parts of their exposé contents like e.g. floormap drawings.

This is not a new idea.

With my own startup Kartenhaus I not only tried something similar by generating parts of the property exposé (especially maps and infrastructure data overviews). After the acquisition of the startup, our parent company wanted us to build a very similar tool that was supposed to replace an external software which was quite expensive to use.

I am sure that the tool that I was supposed to replace is not the only one to do this, but I knew how much they charged for a single text and what their quality was.

The main value proposition then was to undercut their price and provide a no frills user experience, e.g. by entering the address of the property and getting the texts back via email within a few minutes.

The novelty for us in this experiment was to target users by a specific profession. We were unsure whether or not people are attainable to a B2B ad while browsing Facebook with their personal accounts.

You Know It When You See It

With the learnings of our last experiments, Josua and I wanted to change a few things this time:

• Make it much clearer what the product is, what it does and how it works.
• Reduce clutter on the landing page. We initially wanted to reduce it to only a hero section, but eventually went for hero, pricing and testimonial.
• Spend even less time on execution. This time, the landing page took less than 2 hours.
• Be as clear as possible in the ad. Formulate both the value, the process and the pricing.
• Decrease feedback cycle time to 2 days.

Here’s the landing page we came up with:

In the hero section, we added the possibility to enter an address (with a fancy autocomplete using Here’s Autocomplete API. Totally unnecessary, I know, but I wanted to build it) and a business email to receive a free text for the property’s address within 10 minutes.

All of the necessary interaction was above the fold. This is different from our previous experiments, where users had to scroll to a dedicated CTA section.

We then paid for ads on Facebook with our usual 40€ budget and targeted real estate agents in Germany (by interest instead of job title, which is apparently the way this works on Facebook). To reduce the feedback cycle time, we went for a 20€ daily budget instead of our usual 10€. That way, we got feedback within 2 days instead of 4. This worked out without any noticeable effect on CPC or CPM, so this seemed like a viable way.

These were our metrics:

• 20€ per day ad budget
• 2 days campaign duration
• 75 clicks
• 11 leads
• 0.53€ CPC
• 3.64€ CPA
• 8,304 impressions

Compared to our previous experiments, there’s quite a lot of difference. First and foremost, 11 leads is fantastic. That’s a whopping 14.6% conversion rate — way above what I’d ever state in an xyz hypothesis. The click-through-rate (CTR) of 0.903% was lower than what we usually see.

We interpreted this as being due to the ad being very specific and acting as a filter leaving only those who were genuinely interested in the service to click and then converting with a much higher probability.

Overall, the CPA of 3.64€ is a great baseline value and seems to provide a great opportunity for a sustainable business. When the form submissions started flocking in and the metrics were starting to look good, it really felt like this experiment was a success. We immediately knew that there may be something here. Maybe this is the great differentiator for such kinds of super fast validation experiments: You know it when you see it.

I can’t compare apples to apples, but my main take aways from this experiment are the following:

• Facebook ads are a viable way for acquiring traffic on a Fake Door MVP in a B2B setting.
• A simpler and yet believable landing page provides clarity and a more stringent user flow (reading the hero, scrolling through features, reading the testimonial, go back to the top and fill out the information).
• Condensing the ad budget on a shorter time frame does not seem to affect metrics too much and is a viable way to shorten the time to data.

What’s next?

First, a qualitative follow-up. We followed up on those leads by email and asked for an interview. So far, none of our attempts received any love.

Second, another iteration. What we could’ve done better:

• Instead of a success message and then following up, clearly manage expectations by being transparent. This will probably lead to a higher willingness to interview.
• This experiment was great for estimating interest. The skin in the game was quite low, though, because we especially stated that the first text was free. I feel like this introduced a bias and a second experiment with higher stakes would be necessary. I am still not a 100% sure about the best way to do this elegantly and reliably.

I am not sure whether or not we will do a second iteration, though. Actually building this service won’t be much fun and the learning I wanted to get out of this (does Facebook work for a B2B Fake Door MVP?) was answered. On the other hand, finding a solution on how to make the commitment more meaningful by implementing a believable fake payment would be something this business idea could still be useful for.

For now, this confirms to me that such an experiment can lead to actual data. There was definitely something there and that feels good, but I’m more eager to try something different next time.

As always, I will keep you updated.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

During my Kartenhaus journey I had to learn the value of a proper commitment during validation the hard way: We needed 2 pivots to actually understand when something that users say is actually reliable. In this blog post, I want to explain:

1. Why commitments are necessary
2. and what kinds of commitments are suitable to gauge demand.

Skin In The Game

Alberto Savoia uses the term Skin In The Game in his book The Right It to evaluate the reliability of validation experiments. Skin In The Game loosely means having a stake in the matter and supposedly has its origins in gambling (like throwing animal skins in the pot at a game of poker). His approach of pretotyping is already data-driven, but he stresses the importance of the data pointing to demand in a meaningful way. And that means that the data must show that the demand is genuine.

Savoia is not the only one with this kind of view. Rob Fitzpatrick basically dedicates a whole book, The Mom Test, to this kind of problem. He shares methods on how to conduct interviews that make it impossible for interviewees (not even your mom) to lie to you when it comes to how much value your idea would provide for them. He agrees that a commitment is the best indicator for genuine demand.

In short: Without a commitment your assessment of value risk is almost meaningless.

What commitment, tho

Taking Savoia’s and Fitzpatrick’s views into account, there are three kinds of commitments that can be used in early product validation: Personal info, time and cash. Let’s talk about each of them.

Personal info

It may seem obvious, but when visitors visit your page and leave their personal information, this can be a commitment. But it has to be genuine information and, if compatible with the experiment, should enable a qualitative follow up, e.g. a phone call.

But not only the user’s own personal information may count as Skin In The Game. Especially for qualitative validation, an introduction to or contact information of another person can count as such. By giving us other people’s information, the person puts her social reputation on the line for us. That’s a strong commitment!

Time Spent

When people are willing to spend their valuable time on learning about the product, this can also count as being genuinely interested in it. This can be the case for e.g. online demos, phone calls, meetings or watching lengthy videos. Done right, this is a powerful tool for both online and offline experiments.

Cash

A cash commitment is the crown jewel of commitments and works in both quantitative and qualitative environments. If people wave with their checks for the promise of using something in the future, that’s a great sign. The applicability varies a bit, though. It may be legally challenging to just add a Stripe checkout to your pretotype landing page that provides nothing in return. For wizard of oz MVPs, where a service is performed manually behind the scenes, this may be a viable form of validation, though. Cash commitments shine in B2B environments where interviews and negotiations are done in person.

Long story short: Cash is king.

Score your commitments

To compare different setups or iterations, it may make sense to create a scoring for each run. I like Savoia’s approach of assigning points to the commitments. A verified, genuine piece of personal information counts as 1 Skin In The Game, as well as 1 minute of time or 1€/$ given as a cash commitment.

The actual assignment may vary (e.g. I personally weigh phone numbers higher than mails and cash commitments may depend on the currency), but this way the experiments get a lot more comparable.

Commitments aren’t everything, but without them, everything is nothing

I had to learn this the hard way. When founding my own startup, it took 2 pivots to actually understand the necessity of commitments. Before the first one, we cared only about our idea, not the users. Before the second pivot, we developed our software together with the users. This worked fine until payday, when people started turning away (”I helped you build this, now you want me to pay for it?”). This painful experience taught me the importance of having commitments first before investing time and money into products that don’t provide genuine value to users.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

Pretotypes usually provide binary data for each user visiting your page: Lead or Leave. While this is an awesome way for validating demand, it is unsufficient for identifying the next steps. As product managers, we need additional information. To explain how we can overcome this information gap, in this post I want to dive deeper on the following two points:

1. Quantative validation experiments like Fake Door MVPs are great, but they have flaws — especially in identifying iterations that make sense
2. A qualitative aspect helps overcome these flaws, so aiming for a follow-up leads to much more informed iteration decisions.

I will walk you through both points by using my own experiments as a reference. Let’s dive in!

Why Do They Fail Me?

Fake Door pretotyping experiments are a fast and cheap way to assess the value risk of your business idea. They are usually done by creating a landing page that advertises the product or service in question and providing a way for visitors to express their interest. By collecting some sort of skin in the game (e.g. personal info, time investment or a cash commitment), this creates a meaningful indicator for demand.

After this, you can just get some traffic e.g. via paid ads and measure the relative amount of people showing interest. If this is within the range needed for a sustainable business and subsequent experiments show similar results, this is a good sign.

In theory, this approach provides a couple of advantages:

1. These kinds of experiments are fast. We’re literally talking about hours to your first meaningful set of data.
2. They provide a good first impression of acquisition costs and other relevant metrics as well.
3. They can be easily adapted to be the real thing: Add a stripe checkout and you’re good to go.

Sounds awesome, but here’s the catch: Nailing the landing page is not an easy task at all.

It may be obvious, but I greatly underestimated the amount of uncertainty there is in a simple landing page. Things like copywriting, images, examples, configurators, CTAs, etc.: Much can go wrong. With a binary output like “Did this user leave their contact info or not?”, it is hard to figure out what about the landing page is problematic. And when it’s unknown what’s wrong, coming up with a meaningful iteration that resolves those issues is really hard.

Recordings Trump Analytics

Good analytics with a lot of events can help alleviate some of these issues. E.g. tracking multiple scroll events, button clicks etc. can provide a sufficient understanding on what puts off your users. But I rarely found a simple analytics setup to be satisfactory in this regard. I feel that events usually don’t tell the whole story but it is rather the time in between those events that contains the juice of insights.

Seeing what sections users actually read, what else they spend time on, how they jump from one section to the next and where they finally leave the page is incredibly valuable information. To me it seemed like only with this kind of information it is possible to deduce which sections are unclear, which sections draw attention and where people are experiencing friction on their way to get in touch.

When I first used user recordings instead of simple analytics, it was eye-opening. I already concluded in an earlier article that I will never again conduct pretotyping experiments without user recordings. But this isn’t limited to user recordings. More generally, it is this complementary qualitative aspect that’s really helpful in validation. If your experiment confirms your hypotheses at first try, well, lucky you, but chances are it doesn’t. And having a treasure trove of informationwhyit doesn’t is super helpful for the follow-up experiments.

Always Go For The Follow-Up

With this in mind, it makes a lot of sense to plan for your experiment to provide ways for qualitative follow-ups beyond recordings. In our second pretotype, we intentionally included a 30 minute call where the user tells us about her travel preferences.

In this call we’d have the opportunity to ask some questions about the underlying problems as well and thus have more qualitative aspects that increase the learning in such an early stage of validation.

This principle works not only for Fake Door MVPs but for any kind of experiment and even for later stages of the product journey, e.g. through feedback forms or training sales and support staff to ask the right questions: Getting directly in touch with your users is always a good idea.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

It’s done! As announced in my last blog post, I’ve completed a second attempt of my 12 in 12 businesses challenge together with my coworker Josua.

In this post I will

• briefly explain the business idea
• share the insights and decisions regarding both iterations
• and assess what I learned

No further chit-chat, let’s dive in!

The Idea: Custom Travel Itineraries

When I was travelling around the world in 2016/2017, I was quickly annoyed by all the touristy kinds of activities. Turns out that even the insider tips and hidden gems in the Lonely Planet were everything but (who could have known, right?)!

So I increasingly put more time and effort into researching how to do stuff the local way: food, accommodations and transportation. To find out how to take the local train to a market a bit outside of Bangkok that we wanted to visit, for example, took maybe half a day.

Motivated by this experience, I thought this could be a nice idea to test: Provide customized travel itineraries that contain all the insider information needed for authentic travel experiences.

Of course, I don’t have the expertise to do this for all countries people would like to travel to, so I could obviously not provide this service in case someone’s interested.

But that’s actually a problem I’d have loved to have: People interested in this kind of service.

It seemed like we could very well do some Fake Door/Wizard of Oz hybrid MVP out of this: Create a landing page advertising the services, add a contact form for people to get a call with their “travel expert” (yup, that’s us!) and then manually research and create the custom itinerary once I know their preferences.

This does not at all scale, of course, but it doesn’t have to! I want to assess first whether or not there’s value and if this actually solves a problem worth solving before worrying about scaling at all.

Iteration 1

I pulled out my Next.js starter with Tailwind, Analytics and Co. already set up and just started adding a rough outline for the sections. We wanted to stress the outcome of the service, so the main piece of information was an example itinerary for 3 days in Bangkok. For this, we just used the notes from my own travels that I’ve shared with friends already. Easy!

We chose a price point of 99€ per country. There was no real reasoning behind this except that for a trip that’s easily spanning weeks or even months, 99€ is not a significant amount of money. And it seemed to me that this can be profitable once semi-automated.

The last thing we added was a pretty simple 3-step configurator where people could choose their destinations through a map or a list, add their dates and then leave their personal info.

Again, we went for paid ads on Facebook. I liked the targeting possibilities in my last experiment and this seemed to be quite similar. Also, I wanted to get a better sense on whether or not Facebook ads are a good way to do B2C pretotyping experiments.

Here are the results:

• 10€ per day ad budget
• 4 days campaign duration
• ca. 50 clicks
• 1 lead

That’s less than ideal. We assumed that 5% of visitors would be interested enough to leave their personal information. But still, we got at least one person to do so. The follow-up didn’t lead to anything, though, because I didn’t care about validating the contact form. I hoped that simply showing fields as required and forcing a checkbox would be enough.

On the other hand, some people seemed to be quite interested. The recordings showed that people spent time reading the content on the page. Even the pricing didn’t seem to throw people off. And yet, the configurator was not used beyond its first step.

It gets a bit fuzzy here, but there were two interpretations:

• After users were scrolling through the page, there was no clear next step for them. So they scrolled back up and left. The configurator did not provide the value/credibility I hoped for, it actually only confused people.
• It seems like people didn‘t quite understand what they get.

Iteration 2

So in the second iteration we made quite a few changes:

• Make the service more tangible by advertising a custom „travel insider package“. I changed the visuals to show a book much like a photo book, pictures and personal notes and letters, supposedly from the personal travel expert
• Get rid of the configurator. It was a clear symptom of „this would be so cool“, so I built it. But it was only annoying. Stupid me!
• Make the 3 step process clearer so people know how this works.

The result? Still nothing. Well, it was worth a try!

The numbers were more or less the same like on the first iteration, with the difference that this time around nobody signed up.

It didn‘t feel like all is lost, though. People still showed interest reading through the sections, maybe even more so than in round 1. We could iterate over this some more, make it clearer and more concise.

But then again, we were not too attached to this idea. My goal is understanding pretotyping as a means of validation. So it makes sense to move on and test the next idea.

What‘s bugging me a bit is that this is another failed attempt using the same Fake Door MVP approach as last time. 2 is not necessarily a pattern, but maybe I need to try something else for the next idea. Spoiler alert: I will!

Learnings

To summarize, I gained two very valuable insights out of this experiment in particular.

The first is to communicate the product or service to test as clearly as possible. In these kinds of experiments, you’re paying for a few seconds of the users’ attention. These few seconds should not be wasted through being unclear. In this case, we should have clearly stated what people get for signing up and even the “insider package” was still not clear enough.

The second is to provide an unambiguous way to move forward. A configurator may be nice and it may be fun to build one, but it’s basically just a bunch of unnecessary clicks.

I hope that this will get better in the next experiments. I feel like the Fake Door plus paid ads approach can actually work quite well, so I want to get more creative in the next ones.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

It was through reflecting on the last 12 months in this blog post that I came up with the desire to execute more validation experiments, especially quantitative ones. I already wrote about the first one of those experiments here and I am launching the second iteration of the second one just now.

By now I’ve gotten a good sense for what’s needed to pull off those experiments and how much time it consumes. That’s why I want to make an official challenge out of this by announcing that I will be validating 12 product ideas over the course of one year. Or: 12 Businesses In 12 Months.

As you’re likely into product, I think this challenge might be of mutual benefit: You, my readers, are my commitment device and I will share all my insights in return. To stay in the loop, subscribe to this journey.

To kick things off, in this post I will:

• Write about the aim of the challenge,
• explain what will be hard about it
• and what kinds of experiments I will choose

omethy y u do dis

In the blog post mentioned above, I already said how I identified the need to acquire more experiments with the kinds of experiments we advise our customers to do.

I’d like to be at the point of having or discussing an idea and instinctively know which setup is fastest, cheapest or most reliable for validating that particular idea. In the best of all worlds, I’ll already have done a very similar experiment and can give advice from first-hand experience.

This is my primary objective.

But apart from this aspect of learning, I’d like to build a track record for this kind of early and fast product validation.

The last aim is to build passive income streams. This one’s the most unlikely to happen, at least in meaningful quantity, especially because crossing the chasm between a more or less validated idea to a business that works without much work requires a lot of work which I’ll most likely not have. Which brings me to the hard parts of this challenge.

What’s so hard about this?

Oy Timothy, you always say them pretotypes are so fast ‘n all, so what’s so hard about this?

I think that there will be 2 main hurdles in this challenge:

• time constraints
• nothing sticks
• a lack of variety in the experiments

My current state of mind is that a good fake door pretotype will take roughly 4 hours to build (either with or without code, doesn’t matter) and another 2 hours for creatives, copywriting and ad setup. Each iteration will likely take another 2 to 4 hours for reviewing the data and changing the page, copy and creatives.

Carving 4 to 6 hours out of my week just for this is sadly not that easy for me, especially since writing about this challenge as well as my other learnings takes another good portion of my time. Parallel to my full-time job, political activities and chores, this will be my main free-time activity and I will need to spread it over the course of a week. Which is great, since it’s also lots of fun. But a bit of external pressure doesn’t hurt, either.

What I can’t foresee right now is wether or not any of those ideas will actually stick and I am able to identify the necessary countermeasures. If not, I can’t say for sure what the impact of this will have on my morale.

Therefore, but also to explore how to make the experiments even faster than they are now, I will try to vary the setup and the kinds of experiments quite a bit. I have an idea in mind that will likely not need a landing page at all, for example. I still fear that my main approach will be landing pages and paid ads. I will likely choose ideas based on a good approach to validation to maximize learning and get the most value out of this.

Which brings me to the last part of this post.

What exactly will I do?

My colleague Josua and I conducted tons of problem interviews already (I wrote about it here) and by I now they feel both straightforward and slow. Because of this experience, I feel like the learning opportunity is bigger for me with quantitative experiments.

And that’s why I will concentrate on a quantitative approach. This is not to say that I value qualitative approaches less, quite the opposite! The juicy insights, even in a quantitative setup, are coming from session recordings and follow-ups. I will write more about this in one of my next posts, though.

Others have done this, of course

Whenever I talk to my serial entrepreneur friend Johannes about anything, he usually knows someone who’s already done something very similar. Be it a product idea, a blog post or a challenge like this one.

That’s how I found out about Pieter Levels and his talk on How To Build A Startup Without Funding from 2018. In this talk, he shares his approach to moving from idea to exit and talks about how applied this to his own challenge named 12 Startups in 12 Months. I like his approach of just-in-time learning a lot, so definitely check him out.

My approach is different as my primary aim is not generating income but learning and experimenting. I thought about changing the name to make it less similar (and also because it’s not correct, either, I’m not building actual legal entities or making any revenue), but I like the catchiness of it enough to accept the similarity.

I will conduct many of these experiments with my colleague Josua. He will start writing his own blog soon and you will likely find a second perspective on the same approaches there.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

Over the last few months we talked to a lot of people involved in building products. We conducted more than 40 interviews with product managers, innovation managers, startups, CEOs and more. The main take-away? Awareness and understanding of the different risks that need to be addressed varied substantially. The one that was either ignored completely or simply accepted as a given was the value risk.

As you’re reading this, you’re likely involved in building products as well. In this post I’d like to share my understanding of why product is such a risky business but also why I think this can be actively managed. To do this, I will:

• Explain the four kinds of risks that need addressing,
• Summarize the misunderstandings I came across in the interviews,
• Describe strategies to tackle those risks, and
• Emphasize the special role of The One Risk To Rule Them All:Value!

Marty’s Four Risks

As I’m currently making my way through an extensive list of the best books on product management, Marty Cagan’s Inspired naturally crossed my way, too. My key take-away was his division of product risk into four different parts:

We think of four types of questions we’re trying to answer during discovery:

• Will the user or customer choose to use or buy this? (Value)
• Can the user figure out how to use this? (Usability)
• Can we build this? (Feasibility)
• Is this solution viable for our business? (Business viability)

He describes the main task of Product Discovery to systematically assess those risks whenever they are not clear.

In a previous post I wrote for tarent, I concluded that there are two different types of risk that we can tackle with different kinds of artefacts: Product risk and market risk. They more or less reflect value, usability and feasibility risks, but I simply overlooked business viability and the constraints that an organization may possess that limit what kinds of products we can build, their business model or how we market them.

I like Marty’s explanation because it neatly separates the technical aspects (feasibility), the execution (usability) and the demand (value) of a specific product. These insights made me feel like my classification of artefacts in that post was outdated already. Before I give it another try, let’s get some more opinions.

“There’s nothing you can do!”

Since product validation is something that we aim to provide as a service, we used Mom-Test-like questions in our interviews. The most important part to us was getting an understanding of how the interviewees do discovery. For this, we asked to walk us through the whole product development process from ideation to launch.

There were two repeating narratives regarding validation:

• they simply accept the risk that “9 out of 10 products fail in the market”, gather some engineers, raise a budget and start building.
• they buy secondary market research data from external sources, assess market size and competition to estimate revenues, ask engineering what it takes to build it, look each other in the eye and start building.

Some interviewees identified the technical feasibility as the number one risk and a single one explained that they constructed tests by setting up landing pages and measuring signups — only to build the product anyways when too many of those tests showed a lack of demand. To all of them, except the one mentioned earlier, primary user research was synonymous to “testing the UI/UX of the product”.

This is by no means representative, but I was still very much surprised by the outcome. It seems like a common verdict regarding validation is that, to quote verbatim, “there’s nothing you can do” to assess the value risk but to commit, build and ship.

I am not convinced

In the article mentioned above, I categorized Pretotypes and MVPs (in their traditional flavor) as tools to assess market risk and Prototypes and Proof-Of-Concepts to assess product risk. I want to update this categorization to reflect Cagan’s four risks.

Value Risk

To find out whether or not a product (or feature) provides value to a user, we have a wide range of tools at our hands. There are many variations and in-betweens, but here are the two most popular:

A Pretotype is an experiment to measure demand as small commitments like personal information, time or cash, e.g. by leaving a phone number or email on a marketing page. Those experiments are designed to be extremely light-weight in terms of effort and costs. While the reliability of the data is not always optimal, they often result in valuable indications.

Interviews. Done well (e.g. by passing the Mom Test), they can be both fairly quick and insightful. By being qualitative, interviews give valuable hints on the direction the product should be moving towards when the initial assumptions turn out false.

Usability Risk

Usability is usually assessed with prototypes. For digital products, this mostly means so-called high-fidelity prototypes that we put in front of the users to use and simply observe.

Feasibility Risk

This is where we’d try pulling off a rough Proof-Of-Concept of the risky parts over the course of a few days.

Business Viability Risk

Ensuring business viability consists of continually assessing the constraints of the organization. This means that important stakeholders such as Legal, Sales, Marketing, Finance and many more should be taken into account.

Why Value Rules

Building something that in the end nobody’s interested in sucks. In an organization, this is the purest form of waste. There is, therefore, no real point in investing time to assess the other risks when value is still questionable. Cagan sums this up as:

If the value is there, we can fix everything else. If it’s not, how good our usability, reliability, or performance is doesn’t matter. […] One of the biggest possible wastes of time and effort, and the reason for countless failed startups, is when a team designs and builds a product — testing usability, testing reliability, testing performance, and doing everything they think they’re supposed to do — yet, when they finally release the product, they find that people won’t buy it.

This clashes with the approaches revealed during our interviews. If assessing value is so important, there seems to be a natural order of product discovery: Value first, then feasibility/usability while gradually ensuring business viability.

There are exceptions to this rule, of course, but still I want to encourage you to give the value assessment extra care. Coming up with meaningful experiments and executing them is easier and faster than it seems at first, and first-hand data unique to your idea is invaluable for avoiding an expensive flop. So let me finish with another quote:

The worst part of this scenario is that, in my experience, it’s so easily avoided.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

If you’ve been building a service or product before, chances are you tried either quantitative or qualitative (or even both!) approaches to research your hypotheses. In an ideal world, these experiments yield highly reliable results in the fastest possible way and without spending a fortune (either in labor or cash).

But as you probably noticed already, this world is not ideal. For a couple of weeks now, the team and I invested quite a lot of time and money on a series of user research experiments. And we discovered that there seems to be a certain set of tradeoffs regarding those three aforementioned dimensions (affordability, speed and reliability) for most experiments, especially in the quantitative world. This reminded me dimly of any of those Magic Triangles so I coined this set of constraints the Magic Triangle Of Validation (and I don’t know… this somehow made me feel clever).

The decision for/against any of the dimensions is highly dependent on what you want to test and by sharing how we decided to change the focus from one to the other during our iterations, I want to give you some aid for your own experiments.

For this, I will briefly explain how we fixed our quantitative approach’s low reliability and high cost by deliberately deciding to reduce its speed. I will then contrast these findings with our experiences conducting interviews. Let’s dive in.

Spread Thin

The way we first started out with quantitative validation via LinkedIn is a very good way to demonstrate the triangle and was actually what pointed me towards it. In this approach, we constructed A/B/C/D tests for four different customer segments all at once. The goal was to identify both a way of communicating and a segment that works best for our services in a single experiment. But it turned out to be overly ambitious, because this effectively split our budget by 16 for every combination of ad and segment.

Since we were just starting out and therefore didn’t optimize our costs beforehand, the absolute number of interactions with each ad was so low to the point of being largely inconclusive. We set out to generate hard data but ultimately ended up with guess work. Yup! Great job.

So what happened was that for our budget we optimized for speed (by testing 16 different combinations at once) and sacrificed reliability (because of the low absolute numbers per ad) by spreading it thin.

Focus

The big learning of this first round on LinkedIn was that we needed to tweak our approach. It was clear that we needed to first and foremost fix the reliability of the coming experiments, because with absolute numbers like this, we were basically wasting our time. At this point, there were two options:

1. increase our ad spend for a higher amount of interactions overall and
2. focus.

For getting meaningful results for all ads and segments, we’d have needed to increase the spending for the next iteration by a factor of 10. That was obviously not an option. But we were open to compromise on speed and decided to validate single aspects of our assumptions with a lower budget for a single target group.

In terms of the triangle, by shifting from a spread-thin approach to a more targeted one, we moved up on affordability and reliability while at the same time moving down on the speed of our research process. A welcome side effect was that conducting tests with fewer variables (both less ads and less customer segments) enabled us to get a better feel for what worked and what didn’t. This led to dramatically (almost ten-fold) improving our ad metrics as well.

Y U NO INTERVIEW

I touched on the differences of more quantitative approaches from interviews in my last post already, so it makes sense to classify those according to the triangle here, too — especially, since they are so popular not only in the Lean world of product discovery.

In general it seems that interviews are a lot less subject to our control over the parameters. The cost of conducting an interview is almost always close to zero, but the acquisition and execution can be quite time-consuming, which is why conducting a series of interviews can take weeks.

Especially for B2B products and services (where incentives like vouchers are less fruitious) acquiring interview partners can be tedious. We primarily used LinkedIn and even though we automated the process of asking for interviews, it was everything but fast: The contacts are cold and the limit of 300 characters makes it hard to break this barrier.

But both speed and reliability underlie more variance. Especially for the latter, acceptable results can be produced with the right questions, a commitment (Advancement in Rob Fitzpatrick’s words, Skin In The Game in Alberto Savoia’s words) and a good fit between interviewee and customer segment.

Speed, on the other hand, is usually not so great. It generally takes a lot of time acquiring and scheduling interviews. This can be sped up through a good channel towards customers or a great network. Since we had neither, we had no choice but to invest the time pre-qualifying interview partners on LinkedIn to avoid interviews with people who don’t fit our target segment. This naturally slowed things down.

If you have access to a pool of fitting interview partners or a clear understanding where they can be found, speed can be enhanced. Narrowing that down is basically what Fitzpatrick suggests in The Mom Test when he talks about Slicing, but this may not always be applicable. For us, at least with our limited knowledge on the customer segment, it wasn’t.

Affordability, speed and reliability are decisive metrics

By explaining our LinkedIn and interview approaches, I’ve shown how the triangle works in practice. As seen, increasing the spending can increase speed, reliability or both: A series of reliable experiments takes time, but this can be remedied by higher costs. A single experiment with low absolute numbers is unreliable, but this, too, can be cured by parallelizing with a higher budget. Going both fast and reliable therefore takes an even bigger chunk of cash.

By now, we keep these three metrics in mind when conducting our tests. But we’re not the only ones who noticed their importance in product discovery. Alberto Savoia for example suggests optimizing pretotyping experiments for the metrics hours-to-data and dollars-to-data while treating reliability as a given. Alex Osterwalder et al. include Test Cost, Data Reliability and Time Required on their Test Cards, as well.

So while the importance of these metrics is recognized, I hope it may help to view them as trade-offs between each other and visualize them as a triangle.

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

Since you’re reading this blog, chances are you’re already familiar with the Lean Startup movement in the flavors of Ash Maurya, Eric Ries et al. These approaches are already superbly lean compared to a classic waterfall project. But the pretotyping approach that Savoia suggests in his The Right It may provide a much faster way to validate your next big business idea. To explore this technique, I tried it myself.

I want to share my experience, so in order to do that, I will explain what pretotyping is according to Alberto Savoia, how I used his approach for my own business idea and the strengths and limits I discovered so far.

Building The Right It before building It right

In essence, what Savoia says is that it’s important to make sure you’re building the right piece of software before actually diving into building it right. The reason is that most new products will fail in the market, even if competently executed. And in order of being successful you need to have both: a product that is the right it and a competent execution

The problem with his suggestion is: How do we know in advance? How can we solicit feedback on the demand of a product without building it first?

One approach could be to ask people whether they’d buy it or not. The problem is that their opinions usually don’t count for much and people are usually pretty bad even at expressing their own desires in a product. That’s why Savoia stresses the importance of collecting one’s own data and to measure its validity through some sort of commitment (which he calls Skin in The Game). Such a commitment could be time, cash (paid on the spot or as a check) or personal information.

Enter Pretoytping

His approach to overcome this problem of needing data now but building later consists of the following steps:

• Have your business idea.
• Formulate an XYZ hypothesis, e.g. At least 20% of packaged-sushi eaters will try Second-Day Sushi if it’s half the price of regular packaged sushi.
• Transform XYZ into an xyz hypothesis by giving it a local touch: At least 20% of students buying packaged sushi at Coupa Café today at lunch will choose Second-Day Sushi if it’s half the price of regular packaged sushi.
• Conduct a set of very small so-called pretotyping (derived from pretendotyping, a mashup of pretend and prototype) experiments that validate your xyz hypothesis in a matter of hours or days. That means: Without code at all or with just a bare minimum amount of it, e.g. for a landing page.

There are several ways to conduct these experiments. As a source of inspiration, he describes techniques called the Mechanical Turk, the Pinocchio, the Fake Door, the Facade, the YouTube, the One-Night Stand, the Infiltrator and the Relabel. But any experiment or combination of approaches that works for you is fine.

After one or two experiments, there are 3 kinds of results:

1. Instant hit! People start flocking in, signing up for your service, buying the hell out of your product or booking appointments? What are you waiting for? Build the damn thing.
2. Miss! People don’t seem to care. This might be due to bad copywriting, too high a price point, your value proposition just not solving any problems or anything in between. Try identifying the reasons (e.g. via analytics) and tweak your pretotype. If this occurs on multiple iterations, consider abandoning your product idea.
3. Somewhere in between. Try iterating until it’s a clear hit or abandon after multiple iterations.

Woah, that’s fast!

Savoia’s pretotyping approach can be such a shortcut because it skips most of the time consuming processes of qualitative primary user research that most other frameworks suggest. To me, this has two implications:

On the one hand, this feels like a bigger bet because it’s basically rushing into a first version of the idea based on a hunch.

On the other hand, if it turns out that people sign up or even start paying for such a suboptimal version of a product, that’s a huuuge win. On top of that, at least under the right conditions and with a suitable idea, it’s really fast to conduct such an experiment.

Let’s give it a shot

After this brief explanation it’s time to get to the juicy parts of this article: A quick run-down of a B2C pretotype. For this, I will briefly go through the context, the idea itself, our setup, the results and the learnings of our first iteration, the changes and the results and learnings of the second iteration.

A bit of context

After reading the book a while ago, I was pretty stoked to try this myself. So as my colleague Josua and I were going through a few of each other’s business ideas, we figured we should sit together for a few hours over a weekend. We started prioritizing them and then going for the one that seemed to be easy, fast and cheap to pull off!

The idea we chose was the following: Put up 4 to 6 360° video cameras for a wedding to record whatever’s happening in the different rooms.

We didn’t put much thought into pains, gains or value propositions but rather just assumed that something along the lines of “never miss out on any of the funniest moments of your special day” could be met with demand.

• Our XYZ hypothesis turned out to be this: At least 5% of all wedding celebrants in Germany pay more than 4000€ for 6 360° full-length videos of their wedding.
• Our xyz hypothesis was “At least 5 out of 100 visitors to a suitable landing page leave their phone number for a customized offer.”

Setup

We hacked together a landing page with Next.js, Tailwind and Netlify, sprinkled some stock photos as well as a more detailed custom graphic and added a simple “reserve date” form using Netlify’s serverless Form feature. In this form, people were asked to leave their personal information to be contacted by us for a confirmation of the date they chose. This is crucial, because that data is how we intend to measure Skin in The Game.

We designed a quick logo and bought a domain for a generic brand name that we can reuse for other ideas in the future.

After that, we installed an analytics solution and bought ads on Facebook, where we targeted engaged women in Germany aged 26 to 36 on a budget of 10€ per day for 4 days total.

The numbers

Our ad spend bought us 4,439 impressions and 44 clicks. That’s a CPC of just short of a Euro. 7 of those who clicked scrolled down to the end of the page and not a single one contacted us to book a date.

What do these numbers tell us? Well, first of all, the amount of clicks is below the 100 visitors we expected in our hypothesis. This means the data we collected bears a lot less statistical significance than we hoped for. Even ignoring this fact, the results contradict our hypothesis.

Also, our CTR is quite low, which may tell us that the copywriting and/or the image we chose for our ad is not very compelling. This is not necessarily a problem for our experiment, but it means that the costs of our experiment are probably higher than they could be. What’s more problematic is that the bounce rate is too high. There are a few potential reasons for this:

1. The overall quality of the landing page could be too low for such an expensive service and an important event such as a wedding.
2. The visuals are not compelling enough and do not transport the idea well enough.
3. Pricing could be too high, too, but since too few people even got there, this is not too important right now.

Overall, this first experiment is indicative that this service is not The Right It. This should be discouraging, but a single failed experiment is not the end of the world for a product idea. A proper pretotype should first and foremost generate some insight about how to alter the experiment for the next iteration and only after fixing the obvious problems doesn’t change the results even after more experiments, chances are this idea really is notThe Right It.

This brings me straight to the second iteration of this pretotype. But first, I want to centralize our learnings so far: After this first experiment, we found that our analytics were not as granular as we needed to draw clear conclusions. The only data points we got were visits, bounces, scrolls to 90% of the page and filled out contact forms. To handle this, we moved to a different analytics tool to track more events on the page. This is valuable not only for the next experiment regarding this idea but rather changing the default setup for all future ideas.

As a countermeasure for the bounces, we created a short video and added it to the hero section of our landing page to make that section more sticky. If we had higher traffic, this was probably something to A/B test, but given our low absolute numbers, we decided against it.

Round 2! Dingdingdingding, knockout!

This is what the landing page looked like after we implemented the changes mentioned above:

Our second experiment brought us 4,839 impressions and 38 clicks, resulting in a CTR of 0.78%. Again, there were no conversions, but our Analytics now showed more detailed results:

2 people clicked on the CTA button, opening the modal to enter personal information, 10 people spent time actually reading our copywriting, watching the video or viewing our infographic. Still, most visitors left the page as soon as they saw the pricing section. Only one scanned the pricing section first and then started to read more about the service before leaving the page.

So again, what does that tell us? First of all, the CTR went down, indicating that the second ad text was less convincing than the first one. Again, we’re not getting the 100 visitors we aimed for in our hypothesis on a budget of 40€. Still, most of the users bounced. Among those who didn’t, the texts and visuals seemed to spark at least a bit of curiosity, but sadly not enough to drive any conversions. On top, most users were apparently put off by the high price point.

In the end it seems like this second iteration puts further weight on the conclusion that pricing is too high and further supports the interpretation that this service is not attractive enough.

This sucks! Oh, wait, it doesn’t…

If this was a product idea that we were really fond of, these results would’ve been pretty disappointing. But since we did this primarily to learn how we can leverage Facebook ads for getting data on demand fast for a B2C product that’s targeted at a very specific audience, this proved invaluable.

In a real situation, 2 iterations that are based on short of a hundred clicks total are probably too few to call it quits already. At least a few people seemed to be interested in this kind of service and were ultimately put off by the pricing. Adding a lower entry-level option or lowering the pricing overall could potentially increase actual leads. This would likely change the projections of the hard business metrics such a service could generate and, depending on the context, may be a dealbreaker.

And this is exactly the point why this kind of problem is actually a good one to have: Getting a feel for the viability of a solution and its metrics (like CPC, CTR, conversions and pricing) before investing sums that hurt is a huge advantage.

Lastly, the difference in the interpretability of the second iteration compared to the first one convinced me to never conduct such quantitative experiments (or even launch a software product) without detailed analytics ever again.

Bullet Dodged

If the alternative approach had been to just go for it and rent (or even buy) the necessary equipment, get a shiny landing page, print business cards and hire sales staff, that could have ended badly.

In the lean world I would likely have conducted problem interviews that would have taken some time to schedule and, since it is such a niche idea, a lot more to find the necessary interview partners. I don’t want to give problem interviews a bad rap, though, as they are invaluable for their own reasons and just a different methodology for product discovery.

We were painfully slow with this experiment and we were also a bit too elaborate than necessary, even though we cut corners almost everywhere. Setting up the landing page, domain, CD pipeline, analytics and ads initially took about 10 hours of our time, plus coming up with the visuals and copywriting. But having this set up once will eradicate a big chunk of the necessary work for the next idea, speeding up things significantly.

With this at hand, Savoia’s promise of hours to data seems very doable and I’m glad to have this approach of product validation in my tool belt. To save you the hassle of the initial setup, I will share the boilerplate code for this experiment in one of the next mails to the subscribers of my newsletter. So feel free to sign up!

Originally posted on timothy.de. Want honest insights of somebody who validates product ideas for a living? Subscribe at timothy.de/subscribe!

We’ve been in the process of establishing Innovation Consulting inside of a B2B project organization and despite early successes, there were obvious and avoidable mistakes. Here are 3 of them.

All the memes in this post are inspired by the great @jobenja. May my meme game one day strive to become as good as his.

Building something new (e.g. a product or a service) from scratch is always a struggle: It needs a structured approach, but even knowing all the lean startup theory and even having made the same mistakes previously, it is sometimes very hard to apply that knowledge to the situation at hand. If you find yourself pursuing success with your product or service in a similar setup, this may help you avoid some of the pitfalls we encountered.

To show you what I learned over the course of the last 12 months, I will explain briefly what we did wrong, condense the learning from those mistakes and in the end will draw up a plan for the near term for each of them.

A Tiny Bit Of Context

When tarent launched its consulting program as a new division, I met my colleague Frederik who experienced a similar mishap in the startup space as mine. And we soon discovered we shared the same ambition: Preventing those mishaps for other innovators in the future. This gradually led to the founding of a new team, mostly driven by him, going by the name of Innovation Consulting.

There was no official start for the team, but it’s now roughly been a year since it became solid enough to be perceived as a distinguishable organizational unit. We had a few early successes with customer projects through a mixed bag of value propositions around the ideas of lean startup, design thinking, fast mvp development and agile — based on the skills the team members brought to the table. Although our order books were more or less filled throughout the year, it didn’t feel like we were nearing a consistent lead funnel or gaining any meaningful insight regarding customer demand and turning that into a repeatable service.

We spent weeks on slide decks and offers simply by discussing among ourselves and getting feedback from the sales department and the management. Granted, we started having a loose process of customer interviews going, but that was about it.

In retrospect, this is a bit shocking, because we usually champion maximizing early learning, especially through primary research in customer projects. In a way, we avoided eating our own dog food. But in retrospect, this was only the most probable outcome of the three main mistakes we made throughout this first year. Let’s dive in.

The 3 Areas Of Mistakes

#1: Lack Of Primary Customer Research

Although we knew exactly how important it is to get early feedback (primarily regarding demand, not so much regarding UX), we didn’t set up a structured approach to do it continuously. Our hope was that simply recruiting interview partners provides enough learning in itself. We didn’t put enough thought into it to even formulate the hypotheses we tried to validate/invalidate through those interviews.

What triggered a rethinking of this process was:

a) the feeling that the current approach seemed to not move us any closer to this vague vision that at least some of us had in their minds.

b) finally catching up on a lot of reading regarding building products, which included The Mom Test, Value Proposition Design, The Lean Startup, The Right It, Running Lean and many more.

How are we dealing with it moving forward?

From now on, we’re trying to dedicate half of our capacity to user research. To bring structure into it, we intend to conduct a series of both quantitative and qualitative experiments where every single one is matched to a hypothesis that’s either consciously based on assumptions or based on prior experiments. For now, we are trying Strategyzer’s Test Cards along with Ash Maurya’s Validation Plan to keep track of those experiments and to keep them aligned with our most pressing questions. So overall, we feel the need to prioritize research as the most important item on our to-do list and do so in a structured manner.

Plus, and I think this may prove to become a very handy tool in customer projects, I decided to hone my experimentation skills and try to develop an intuitive sense of the best ways to validate different kinds of business ideas. For this, I want to spend some of my time outside of my job on experimenting with pretotypes and MVPs for different customer segments and business models.

#2: Distraction

Customer research consumes a lot of time, especially early on. In an organization that’s built upon the business model of billing time it’s tempting to not invest the necessary time for research but generate revenue through customer projects. It is even more tempting to do so in such a highly flexible, cross-functional team that has a wide range of skills (and is quite expensive, too). This conflict of interests has led to parts of the team always being in projects more or less related to innovation consulting (I, for one, have mainly been in software development projects at least 80% of my time). Such distraction has definitely reduced our ability to generate valuable learnings.

How are we dealing with it moving forward?

We feel like we need to be more vocal about the necessary amount of time to build a service that’s an attractive solution to actual problems. Therefore we will clarify our approach and try to convince the organization to give us the time we need.

#3: Team

One thing I’ve underestimated is how important it is to have a clear vision that’s consistent across the team. Even after all this time and even after several projects, there’s still no consensus regarding what’s the actual thing we’re trying to achieve.

On the other hand, maybe also due to distraction, we are just starting to implement tools that generate trust. In the recent past, we even had stretches of weeks that were spent without having a single meeting where all of the team members were present.

The pandemic and being remote definitely was a contributing factor, but overall it still feels like we are just starting out as a team and do not know each other well enough for a 100% psychological safety and the levels of trust and alignment that make a team fly.

How are we dealing with it moving forward?

We are now starting to implement the more bottom up elements of Management 3.0 outlined in Dominik Maximini’s Agile Leadership In Practice by working on core values, vision/mission/strategy alignment, Kudo cards and more. Additionally, we recently set up one non-remote day every week with time blocked for collaborating as a whole team. Instead of having one recurring weekly meeting, we are trying a daily meeting in the hope of increasing both the amount of touch points and flow of discussion.

It’s a tough challenge, though

To put this into a broader perspective, I’ve come to feel like some kinds of businesses are easier to validate than others. For services, especially those that are highly individual like consulting, it is hard to condense a value proposition that fits more than one single client. The interviews we conducted so far were mainly inconclusive because we haven’t been able to acquire many interview partners that matched our anticipated problems (creating successful digital products often fails). This may be because either:

1. The problem does not exist,
2. there’s no awareness of the problem in the market or
3. it’s hard to see in advance if the person carrying a certain job description (innovation manager, product owner, product manager, director) is actually in charge of creating products end-to-end, making the selection of interview partners more of a trial and error process.

So far, either option is possible, but for now I am leaning somewhere between numbers 2 and 3. 2 contains an educational component: it’s hard to strike a balance between those that are aware of the problem and therefore developed the means to overcome it (e.g. leaner development process or soliciting UX feedback are the aspects mentioned) and those that don’t even know that there might be a leaner way to innovation than the old-school waterfall. The former now think they are doing fine since they educated themselves and are ready to take over the world and hence don’t seem to have a problem anymore while the latter don’t even think they have a problem in the first place. Number 3 just makes it incredibly hard to find the right people to talk to, which slows down the learning process.

So maybe on top of not having found the ideal tactics yet, we chose a hard game as well.

The Gist

I described that we’ve been building a new consulting branch dealing with building the right products and preventing their failure in the market. Although some of us knew how important it is to maximize learning in the early stages of a new product or service, we were dumb enough to not thoroughly apply these lessons to this undertaking.

The lack of primary user research in our approach, distraction created through customer projects only partially dedicated to innovation consulting and a delayed teaming process were identified as the main mistakes we made so far. To overcome those, we plan to embrace a more structured approach to learning and prioritize it as well as improving the way we are working together as a team. Plus, I will conduct a series of unrelated pretotyping experiments to become better at it.

Especially for the latter, I will keep you posted!

This post was originally posted at timothy.de.