Skip to content

Tag: startup management

User feedback: A startup perspective

User feedback: A startup perspective

Published by Joni on March 30, 2017

Introduction – the first-order problem

The first-order problem for startups often is, they are not making something people want enough to pay for. As you can see from the CB Insights data, founders identify this as the most common reason for failure.

Figure 1 Reasons for startups failure

Notice the connection between 1 and 2: We can paraphrase that as “there was no market need, therefore the startup ran out of cash.” Investor hype aside (think of Twitter), most startups don’t have the luxury of living years with negative profitability. This is why I emphasise the part ‘enough to pay for’ – contrary to Andrew Chen and others who advice to first get users and then figure out how to make money [1], I’m of the small but growing ‘direct monetization’ school of thought [2].

The solution for this problem is evident: find out from users what they want or need, and then build it.

Second-order problem

But, this is followed by a second-order problem: How should you learn from the users? It’s not evident at all; let me elaborate.

  • First, if you ask users what they want, you get inaccurate feedback because the users don’t know all the possibilities. In other words, people don’t know what they want (feel free to insert a Henry Ford quote here).
  • Second, if you show them a demo, you get inaccurate feedback because your product is not ready, and the users cannot magically “imagine” how it would solve their problems, if it was ready.

Lean to the rescue?

Eric Ries (video), and a large number of his followers (video), advocate ‘Minimum Viable Product’ (MVP) as the solution. The theory goes that “it’s enough your MVP demonstrates the solution”, as potential customers is shown how the product essentially solves their problem, and for the rest they fill in the gaps. The key difference to a demo is the tight connection to the problem – we only need to show the logical connection between problem and solution (this is referred to as product-solution fit [2]), and for that we necessarily do not need even a laptop.

However, the MVP approach has two major problems. First of all, for many problems you cannot create an effective MVP. Consider Apple Pen, or many other products of that company. “See, here’s a pen – would you use it?”. It’s not very effective – you miss all the subtleties that the final product has and that the people pay for. Oftentimes, they pay for fine details, not for the hard crude solution. For this reason, the final product often ends up being very different from an MVP which is closer to a prototype. Second, there are complex problems which have, say, one main problem and two sub-problems: For example, to speeden up the set-up of a manufacturing plant, you need to solve logistical bottlenecks. But how do you capture that complexity in your MVP? For this kind of problems, it’s all or nothing: a partial solution won’t do. Moreover, they require the kind of deep customer understanding of the customer’s circumstances which is not usually part of the MVP gospel, centered on simple consumer software products as opposed to, say, B2B industry solutions.

I grant that the MVP approach has advantages, as technically, you could solve a complex problem on a flowchart, or communicate your solution as a video (as Dropbox did). I’m just highlighting that it has shortcomings, too. Most importantly, the final product that the people end up buying is often something very different from the MVP. So, maybe MVP could be used as a starting point, but not as the end solution.

How, then?

The best solution, as far as I can see, is this:

Learn and much of the nature of the problems, and then bridge that knowledge with the technical possibilities.

As you can see, this approach closely follows Steve Blank’s customer development.

The main difference is that Blank argues strongly it’s “not focus group” (read: market research), in my opinion it’s exactly that. In fact, you can apply both traditional and novel methods of market research to get to the bottom of users needs and wants. These include etnography, surveys, qualitative interviews, etc. I wrote a separate blog post about market research for startups.

At the core of Blank’s idea is the notion that the founders are testing their hypotheses by customer development. However, those hypotheses originate from innate assumptions about the customer’s reality, and are likely to be biased and flawed. Challenging the hypotheses is therefore must, and not a bad solution at all. However, we can also start by learning about the problem, not from the hypothesis formulation. Ultimately, I believe you can reach the same outcome either by starting from the founders’ hypotheses, or by inducing them from market research [3]. Which is faster and more efficient, probably depends on details of execution. Given the execution is equal, then the accuracy of the original hypotheses is the determining factor — if they are far off, more adjustment has to be done. In comparison, inductive market research, in theory, arrives straight away to the core of the user problems.

Conclusion

In the proposed approach, we take any means necessary to find out what is needed or wanted, and then combine that with the information of what is possible. If you look close enough, this is what marketing is all about – matching supply and demand. Consequently, the role, or competence, of a market researcher, is crucial for a startup organization. They need someone to bridge the technical knowledge, existing in developers’ heads, and customer knowledge, existing in customers’ heads. Often, these two groups don’t speak the same language, so the individual who is mediating is acting as a kind of an interpreter. (S)he has to have the ability to understand both languages — that of technology, and that of ordinary people.

Endnotes

[1] It’s the well-known Y-Combinator motto: “make something that people want”. This can be interpreted as getting users being the priority, which is why I like to re-phrase it as “make something that people want to pay for.”

[2] The major exception for foregoing direct monetization is subvention: e.g., in platforms that seems to be the de facto necessity to even enter the market, while for all startup is may be when users are recruited to learn about them. From an economic point of view, this equals subventing one group of users (early adopters) to improve access to another group (main market).

[2] Problem-solution fit precedes product-market fit, which essentially deals with having a product with a lucrative market.

[3] The same separation exists in the academia: There are hypothetico-deductive studies, and inductive studies.

My other writings on startup problems:

On complexity of explaining business failure

On complexity of explaining business failure

Published by Joni on March 30, 2017

Introduction

During the research period for my dissertation based on startup failures, I realized there are multiple layers of failure factors associated with any given company (or, in reverse, success factors).

These are:

  1. generic business problems (e.g., cash-flow)
  2. individual-level problems (e.g., personal chemistry)
  3. company type problems (e.g., lack of funding for startups)
  4. business model problems (e.g., chicken-and-egg for platforms)

Only if you combine these multiple layers – or perspectives – can you understand why one business venture fails and another one succeeds. However, it is also a relative and interpretative task — I would argue there can be no objective dominant explanation but failure as an outcome is always a combination of reasons and cannot therefore be reduced into simple explanations at all.

A part of the reason for the complexity is the existence of parallel root causes.

For example,

  • A company can said to have failed because it runs out of money.
  • However, why did it run out of money? Because customers would not buy.
  • Why didn’t they buy? Because the product was bad.
  • Why was the product bad? Because the team failed to recognize true need in the market.
  • Why did they fail to recognize it? They lacked such competence.
  • Why did they lack the competence? Because they had not enough funding to acquire it.

Alas! We ended up making a circular argument. That can happen with any failure explanation, as can coming up with a different root cause. In a team of many, while also considering several stakeholders, it is common that people’s explanations to cause and effect vary a great deal. It is just a feature of social reality that we have a hard time of finding unambiguity.

Conclusion

In general, it is hard to dissect cause and effect. Human beings are inclined to form narratives where they choose a dominant explanation and discard others. By acknowledging a multi-layered view on failure, one can examine a business case by applying different lenses one after another. This includes interviewing different stakeholder groups and understanding multiple perspectives ranging from individual to structural issues.

There are no easy answers as to why a particular company succeeds or fails, even though the human mind and various success stories would lead you to believe so!

Why do I love startups?

Why do I love startups?

Published by Joni on March 30, 2017

I’ve dedicated plenty of time for studying and coaching startups. But why do I care? Not only care, but be passionate about them, enough to say I love startups.

I got to think about that, and here are the results of that quick reflection.

1. Startups are about technology

Novelty, innovation, progress… call it what you want, but there is something endlessly exciting about startups. It’s to see them take something which exists and turn it into something completely new. This sounds melodramatic but at its core it’s close to creation, close to being a god. Not meaning to blaspheme, but honor the impact startups have on people’s lives. Of course there is a lot of hype and failure associated with this progress because the process of creation is not linear, but nevertheless the renewal of daily lives is to a great extent driven by startup innovations. We can see them all around us, never stopping to be amazed of what we humans can accomplish.

2. Startups have rebel spirit

They are the anti-thesis of corporations. As much as I love startups, as much I hate (bureaucratic) corporations. Startups are about freedom, creativity and independence — and about power to execute. Some other small organizations share these traits, which is why working with small tends to be easier than working with the big. Even big companies create innovative stuff from time to time, but I’ve seen plenty of cases where new ideas are strangled to death by internal politics. Many large organizations don’t want to change — truly — but they just pay lip service to change and new management fads. They also don’t need to change, because in the short-term the world actually remains quite stable. The change in any given industry does not come over-night which gives corporations plenty of time to adapt (i.e., they can hire and fire many CEOs until they have gradually shifted their focus to something that works).

The rebel spirit of startups can be seen in their desire to take on the world, solve big challenges (not only create vanity apps), and relentless execution and elimination of waste. Indeed, there’s a small optimization maniac inside me who loves startups because they aim for optimal use of resources – that’s the economic ideal. And they have to operate under strict scarcity which fosters innovation – much more exciting of a challenge to solve a major problem when facing resource constraints. You wouldn’t believe they are able to do it, but history shows otherwise.

3. The people and culture are amazing

Anyone who have been bitten by the startup bug know what I’m talking about. It’s energetic, young people that want to change the world for the better. Who wouldn’t get excited about that? On a side-note, it’s actually not to do with age; I’ve seen many mature people get excited about startups as well — so it’s more about mentality than age, gender or any demographic factor. The love for startups is universal – you can see that e.g. in the rapid diffusion of student-run entrepreneurship societies around the world. Startup people care about their surroundings, want to make a change, and are super helpful to one another. Again, this is the anti-thesis of “normal business” where dominant paradigms are rivalry and secrecy.

Startups openly share their ideas, invite new people to join them and are geared more towards collaboration than strategic thinking and self-interest. Even sometimes, coming from a business background, I think they are too nice (!) and neglect profit-seeking to their own demise (this shows e.g. in the monetization dilemma which I examined in my dissertation). However, it’s part of the startup magic at least in the early-stage: purely commercial motives would undoubtedly destroy some of the appeal. Ultimately, it’s the people of diverse backgrounds — IT, engineering, art, business, marketing, corporations — that make the startup scene such an interesting place to be.

4. Startups are never done

This relates to the first point of innovation. Joseph Schumpeter, a famous economist, had the idea of creative destruction which startups almost perfectly embody. When interacting with startups, you can see the world is never ready. The turnover of new companies coming and going, making small, medium and large impacts to their surroundings, is baffling. It’s analogous to research community, where scholars stand on the shoulders of those who came before them, and strive to make contributions, even small ones to the body of knowledge in their disciplines. Startups aim to make a contribution to the society, and are never finished at that.

In conclusion, startups are a fascinating topic to study and interact with. Startups are endlessly inspiring and embody the spirit of progress in daily lives of people. Startup people are a special group of people that willingly share their ideas and experiences to elevate one another.

Startup dilemmas: Feature priority problem

Published by Joni on March 30, 2017

Introduction

It is a common issue for startups applying customer development to discover many customer problems and either relating to that or to their vision include many, many features in their product development roadmap. However, as we know, it is not about the number of features but their quality, i.e. usefulness in solving the customer pain points.

Why is this important?

Having too many features introduces several problems: feature creep for end-users, loss of time and money, etc. One can perceive it as a form of premature scaling, but it is also has negative marketing consequences for positioning and differentiation: what is the startup all about? Too many features can easily cloud the answer. In brief, too many features pose a problem for both the end-user and the startup’s internal operations.

How to address the issue?

Well, it can be framed as ‘feature priority problem’, i.e. what features should the startup focus on. Say you are a “dance app startup”. Based on a prior assumptions and perhaps some customer development activities, you have defined a set of features reflecting what customers want. This set includes:

  • buy dance event tickets
  • get notifications on dance events
  • see dance events in map
  • get driving directions to events
  • learn to dance better (dancing instructions, videos)
  • search dance partner

You could focus on developing all these features, but according to the above logic, it makes more sense to choose the most relevant ones and solve them. If one problem is large enough, solving only that one would be enough to provide real value.

So, how do you determine which features are more important than others – i.e. how do you prioritize? It’s a very simple process:

  1. Tie them to problems (e.g., “I always miss the interesting dance events in my city” –> Get notifications on dance events).
  2. Prioritize problems through customer development (rank-order questions, customer understanding, relative solution gap).
  3. Thus, you have the features prioritized as well.

The customer development activities should therefore focus on setting the problems (and thus features) in order of preference from customer perspective. The more problems there are, the more useful it is to rank them. You can directly ask customers to rank the presented problems. You can also form a general understanding of the magnitude of different problems by interviewing customers.

Finally, ‘relative solution gap’ refers to the ratio between the magnitude of the problem and competing solutions effectiveness in solving it. The ideal would be a combination of MAGNITUDE: high, EFFECTIVENESS OF COMPETING SOLUTIONS: low. The least feasible problem to solve, according to this logic would be where the perceived magnitude (rank) of the problem is low and, moreover, extant solutions are effective in solving it.

Conclusion

To avoid feature creep, startups should prioritize their customer’s problems and associated solutions. Based on this, they are able to create a “market-oriented” product development roadmap.