Archive for the startups tag

Joni

First experiences with startup user studies (ca. 2010)

english
First experiences with startup user studies (ca. 2010)

I was reading through old emails while backing up my Gmail inbox with Gmvault, an open source command-line tool. Among other interesting trips to memory lane, one message was about the first startup user study I was involved with. It was for a life-coaching startup that eventually failed. In retrospect, it’s interesting to reflect on what went wrong and how we could have improved. In that spirit, I’m sharing these notes on the user study.

***

Okay, here’s my analysis based on user feedback.

We have three big issues to tackle at the moment:

  1. value
  2. mobilizing users
  3. clarity and purpose of the service

Value refers to a) providing such benefits customers want to pay for and b) setting the right price point.

Mobilizing refers to practical issue of getting customers to use the service on daily basis – i.e. facilitating the data input process as much as possible.

Clarity refers to layout and functionality of the site.

1. VALUE

a) Problem:

Are users willing to pay for the service?

“Sivusto ei tuonut mitään uutta tässä vaiheessa muihin vastaavanlaisiin sivustoihin verrattuna, paitsi jos sivustonne pysyy ilmaisena.” (“The site doesn’t bring anything new compared to other similar sites, except if it stays free.”)

-> There’s a need to introduce features people are willing to pay for.

I’ll doubt they’d pay at the moment, although we should have asked that in the feedback form.

Solutions:

-> Creating a mobile version for paying customers (cf. Spotify)

“Ehdottomasti mobiiliversiota tarvitaan.” (“A mobile version is absolutely needed.”)

I agree that an optimized version for mobile phones is needed. Technically this would require mobile device detection and loading appropriate html+css files to fit the smaller resolution. Later on, if the service succeeds, an iPhone/Android app would be great 🙂

-> Other additional features for paying users such as meal (1) and training recommendations (2) (integrated in the app)

(1) “You could include an suggestion for the diet. You now have something like 50% proteins, 30% Carbo., 20% fat, but would be great to see already a diet suggestion based on that.

“It could include in the categories some traditional dishes like: Fish and potatos, Pasta and tomato, Kebak, etc…”

This was a constant concern by many respondents. As Valtteri suggested earlier, building meals is a great way of providing value. We could for example divide them to three categories based on nutritional values: snacks (välipalat), light meal (kevyt ateria) and heavy meal (raskas ateria). By combining these three, the service could propose a personalised diet based on consumption and need of calories calculated from person’s weight and other factors.

Also users could be given the possibility to add own meals and make them public for other users, as suggested in this comment:

“Yksittäisten ruokalajien sijaan voisi lisätä malliannoksia ja tarvittaessa muokata niitä samalla tavalla, miten annos pitää nyt koota täysin itse.”

(2) Another idea is creating a mentoring/peer supporting system that enables users to get support

b) Problem: “How much you’re thinking to charge the subscription?”

Solutions:

  1. Yearly fee of 25€
  2. Monthly fee of 2.95€ (“less than coffee cup in Starbucks” 🙂

Free of charge -> revenue coming from advertisements/affiliate marketing

So, I think we’ll need to make a decision now of whether to offer the service for free and acquire sponsors, or make it paid and introduce such features that would increase likelihood of paying.

Also, we can think of providing a free version for free and premium with extra features for a small fee.

2. MOBILIZING USERS

Problem: Users are too lazy/busy to add daily information, ergo the app is not used actively.

“In general I think that it is really great, but the problem is to add the information on a daily basis…. :(“

“Jos palvelua alkaa käyttää niin on riskinä, että sitä vain kokeilee, eikä käytä jatkuvasti”

Solutions:

-> Creating a mobile version that allows on-the-go editing of profile

-> Creating a scheduled email system that allows easy updating (“Did you do the assigned training? Answer ‘yes’ to this message and information is updated automatically to your Muscler profile”)

-> Making it possible to update via sms? (requires an sms gateway + might be complex to use)

-> Creating community pressure for using the service (assigning personal mentors who have access to a person’s progress data — while conserving anonymity)

-> Offering rewards after completing milestones (e.g. reductions of sponsor products such as proteins)

3. CLARITY AND PURPOSE

“On vähän epäselvä. Ohjeet voisi olla vaikka tyyliä ‘ranskalaiset viivat’ settiä” (“A bit unclear. Bulleted instructions needed”)

“Parantakaa/tiivistäkää putkea, joka alkaa tarvoitteiden asetannasta ja etenee seurannan aloittamiseen ja raportteihin, tällä hetkellä minun tulee itse välillä muistaa edetä seuraavaan kohtaan ilman kehhoitusta/vinkkiä” (“Improve the process starting from setting goals to tracking and reports – atm, i have to remember to move myself”)

“Tutoriaali tai step-by-step-ohjeet olisivat hyvät :)” (“tutorial or step-by-step instructions would be great”)

-> Inserting tooltips

-> Creating “Proceed to [next]” buttons (Proceed to Tracking/Reports)

-> Creating a “How to use?” page

Besides the video, a separate “How to use?” page is needed. a bullet-type list would do ok, like suggested by the user. it could contain steps of using the service along with links, being short and simple.

“Mitä tarkoittaa tarkalleen Vahvistus tai ‘Lisää kestävyyttä’. Näistä olisi hyvä olla tietoa, sillä eri lajien ihmiset saattavat nähdä nuo eri tavoin.”

(“What does strenghten or more endurance mean?”)

-> Maybe these could be removed and focus on mass increase?

4. Bugs & Language

“Suosittelisitko palvelua ystävillesi?” kohdassa sanasta “Kyllä” puuttuu toinen l-kirjain (“Kylä”). :)”

-> Kylä should be Kyllä on feedback page

“Tavoite laatikon perässä saisi olla mitä yksikköä siinä halutaan”

-> Add units after goal form field to clarify what is asked.

“Kun lisäsin ruokia omalle “tililleni”, ei missään tuntunut olevan hiilihydraatteja. Se valikko, mistä ruuat valitaan, voisi olla selkeämpi (esim. isompi ja ADD-nappula aina samassa kohtaa). Haku-toiminto ruoka-aineille olisi myös kätevä.”

-> search function for nutrition, bigger add button with fixed position

“Itse tykkään etsiä aina lisätietoja varsinkin tällaisista urheiluun liittyvistä aiheista, joista löytyy aina monia mielipiteitä. Siksi olisin kaivannut esim. linkkejä lisätietoon “The Harris Benedict Equation” -menetelmästä”

-> Insert a link to “The Harris Benedict Equation”

“-Report is showing for today: 364% ACHIEVED (!!??)”

This is an issue I spotted myself, too. There must be something bizarre in the calculation formula, or can you give me example of a proper diet of 100% per day for let’s say a person weighing 60kg?

“- Many times a orange button option is dimmed, and little confusing (do I need to enter more infp? Does it work?)”

-> The button should be yellow in normal state and changed in mouseover, not other way around.

In reports/diet, “viikottain” should be “viikoittain”

Traning advice -> Training advice

Also, server location still shows Ukraine. There’s still some timelag which can be annoying.

There’s a logic problem -> when i insert a weightlifting training of 5 x 35kg in goals and then go into tracking, i shouldn’t reinsert the same stuff. i should be able to select the activity and then check that it’s done. if the weight was different, it should be changed in goals and not here.

***

Joni

Thoughts on Remora’s Curse

english

Remora’s curse takes place when startup attaches itself to a large platform in the attempt to solve the chicken-and-egg problem of getting users. The large platform then exercises its greater power to void the investments made by the startup into the platform, essentially causing more or less deadly delays and needs for re-design. The idea originates from Don Dodge who wrote about the Remora Business Model.

Examples:

  • Facebook stopping “friends of friends” access
  • Twitter killing ecosystem players (cf. Meerkat)
  • LinkedIn killing Developer program
  • Google’s Panda update dropping sites

The popular platform is not your friend. If their interests collide with yours, they will walk over you. Period.

Solutions:

  • diversify – don’t be dependent on only one platform
  • limit the overall dependence on platforms; i.e. do not make integration your secret sauce (aka “never build your house on rented land”)
  • capture the users (envelopment): when you get them to visit for the first time, make them yours; e.g. email subscription, registration

Purposefully limit the role of platform to user acquisition as opposed to being core value prop. Platforms, seen this way, are just like other marketing channels – if they work, scale. if not, kill. The benefit of platform integration is that it may partially solve the cold-start problem: get faster traction and accelerate user growth.

Read more about Remora’s curse in my dissertation: Startup dilemmas – Strategic problems of early-stage platforms on the internet

Joni

The Role of Assumptions in Startup Pitching

english
The Role of Assumptions in Startup Pitching

More than truthfulness of the numbers, investors evaluate the assumptions underneath a pitch. They are not asking “Are these numbers real?” but “Could they be real?”.

The assumptions reveal the logic of thinking by the founders. When examining them in detail, one should get logical answers to questions like:

  1. How many sales people are needed to hit the sales goals?
  2. How much will it cost to achieve the sales target?
  3. How much is the cost for acquiring a new customer?
  4. How long is the average sales cycle?

(Assuming an enterprise sales case; the questions in a B2C market would be different, so you need to consider the circumstances.)

The investors are looking for “intellectual rigor” and “completeness of thought” from the founders. Therefore, the pitch needs to show that you understand how to run the business, and how those actions are linked with growth within a defined timeframe. Like one investor said, it is better to be roughly right than exactly wrong.

Joni

Startup due diligence: Some considerations

english
Startup due diligence: Some considerations

We had an interesting week with the Qatar Science and Technology Park (QSTP) that had invited several high-profile entrepreneurs from the US to evaluate the technologies of Qatar Computing Research Institute (QCRI).

Unfortunately, I wasn’t able to attend all the sessions, but from what I saw I picked up a few pointers for due diligence work done by investors when evaluating the startups. Here they are:

  • customer references => who are the existing customers and what do they say?
  • investor references => who are the existing investors and what do they say?
  • competitors => feature comparison & position map
  • technology => expert evaluation
  • IPR => defensibility of the core tech
  • key competitive advantage => if not the core tech, then what is the thing preventing others from replicating your success?

Conclusion

It’s worthwhile to mention that the formal due diligence process is something different from an informal one – the latter takes place when the investor does some initial inquiries about the team and the tech, and then decides whether he wants to pursue further discussions. After reaching an adequate level of confidence, formal and detailed due diligence procedures conducted with the help of experts (e.g., tech, legal, science) ensue.

Joni

User feedback: A startup perspective

english
User feedback: A startup perspective

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:

Joni

Startups! Are you using a ‘mean’ or an ‘outlier’ as a reference point?

english
Startups! Are you using a ‘mean’ or an ‘outlier’ as a reference point?

Introduction

This post is about startup thinking. In my dissertation about startup dilemmas [1], I argued that startups can exhibit what I call as ‘reference point bias’. My evidence was emerging from the failure narratives of startup founders, where they reported having experienced this condition.

The reference point bias is a false analogy where the founder compares their startup with a great success case (e.g., Facebook, Google, Groupon).

According to this false analogy: “If Facebook did X and succeeded, we will do X and succeed, too.

A_x | B_x –> S

or doing A ‘x’, given that B did ‘x’, results in success.

According to a contrary logic, they ought to consider the “mean” (failures) rather than the “outlier” (success) because that enables better preparation for the thousand-and-one problems they will face. (This is equivalent to thinking P(s) = 1- P(f), or that eliminating failure points (f) one can achieve success (s); which was a major underlying motivation for my dissertation.)

Why is this a problem?

Firstly, because in the process of making decisions under the reference point bias, you are likely to miss all the hardship left out from the best practices outlined by the example of your outliers. In other words, your reference point suffes from survivorship bias and post-hoc rationalization.

But a bigger, and a more substantial problem in my opinion, is the fundamental discrepancy between the conditions of the referred success case and the startup at hand.

Let me elaborate. Consider

A{a} ≠ B{b},

where the conditions (a) taking place in your startup’s (A) market differ from the conditions (b) of your reference point (B). As a corollary, as the set of market conditions of A approach B, the better suited those reference points (and their stories & best practices) become to your particular scenario. But startups rarely perform a systematic analysis for discovering how close the conditions whereupon certain advice or best practice were conceived match those at hand.

As a result, discrepancies originating from local differences, e.g. culture, competition, etc., emerge. Some of these dimensions can be modeled or captured by using the BMC (Business Model Canvas) framework. For example, customer segments, distribution channels, value propositions — all these can differ from one geographical location or point in time to another, and can be systematically analyzed with BMC.

In addition to BMC, it is important to note the impact of competitive conditions (a major deficit in the BMC framework), and especially that of the indirect competition [2]. At a higher level of abstraction, we can define discrepancies originating from spatial, temporal, or cultural distance. Time is an important aspect since, in business, different tactics expire (e.g., in advertising we speak of fatigue or burn indicating the loss of effectiveness), and there are generally “windows of opportunity” which result in the importance of choosing the correct time-to-market (you can easily be too early or too late).

So, overall, reference point bias is dangerous, because you end up taking best practices from Twitter literally, and never end up making actual money. In particular, platform and freemium businesses are tricky, and based on my experience something like 90% of the reference point outliers can be located to those fields. It should be kept in mind that platforms naturally suffer from high mortality due to winner-take-all dynamics [3].

In fact, one of the managerial implications of my dissertation was that platform business may not be a recommended business model at all; at least it is one order of magnitude harder than a your conventional product business. The same goes for freemium: giving something for free in the hopes of at some point charging for it turns out, more often than not, wishful thinking. Yet, startups time after time are drawn towards these challenging business models instead of more linear ones.

That is why the general rule “This is not Google, and you’re not Sergey Brin.” is a great leveler for founders overlooking cruel business realities.

But, when is outlier a good thing?

All that being said, later on, I have realized there is another logic behind using reference points. It is simply the classic: “Aim for the stars, land on the moon.”

Namely, having these idols, even though flawed ones, encourage thousands and thousands of young minds to enter the startup scene. And that’s a good thing, resulting in a net positive effect. Sometimes it’s better not knowing how hard a problem is, because if you knew, you would never take on the challenge.

Conclusion

In conclusion, my advice to founders would be two-fold:

1) Use reference points as a source of inspiration, i.e. something you strive to become (it’s okay wanting to be as successful as Facebook)

2) But, don’t apply their strategies and tactics literally in your context.

Each context is unique, and the exact same business model rarely applies in a different market, defined by spatial, temporal and cultural distance. So the next time you hear a big-shot from Google or Facebook telling how they made it, listen carefully, but with a critical mind. Try to systematically analyze the conditions where they took place, not only “why” they worked.

End notes

[1] Salminen, J. (2014, November 7). Startup dilemmas – Strategic problems of early-stage platforms on the internet. Turku School of Economics, Turku.

[2] That is, how local people do things differently: A good example is WhatsApp which was not popular in the US because operators gave free SMS; the rest of the world was, and is, very different.

[2] Katz, M. L., & Shapiro, C. (1985). Network Externalities, Competition, and Compatibility. The American Economic Review, 75(3), 424–440.

Joni

On complexity of explaining business failure

english
On complexity of explaining business failure

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!

Joni

Belief systems and human action

english

What people believe, sometimes because real because of that.

1. Introduction. People are driven by beliefs and assumptions. We all make assumptions and use simplified thinking to cope with complexities of daily life. These include stereotypes, heuristical decision-making, and many forms of cognitive biases we’re all subject to. Because information individuals have is inherently limited as are their cognitive capabilities, our way of rational thinking is naturally bounded (Simon, 1956).

2. Belief systems. I want to talk about what I call “belief systems”. They can be defined as a form of shared thinking by a community or a niche of people. Some general characterizations follow. First, belief systems are characterized by common language (vocabulary) and shared way of thinking. Sociologists could define them as communities or sub-cultures, but I’m not using that term because it is usually associated with shared norms and values which do not matter in the context I refer to in this post.

3. Advantages and disadvantages. Second, the main advantage of belief systems is efficient communication, because all members share the belief system and are therefore privy to the meaning of specific terms and concepts. The main disadvantage of belief systems is the so-called tunnel vision which restricts the members adopting a belief system to seek or accept alternative ways of thinking. Both the main advantage and the main disadvantage result from the same principle: the necessity of simplicity. What I mean by that is that if a belief system is not parsimonious enough, it is not effective in communication but might escape tunnel vision (and vice versa).

4. Adoption of belief systems. For a belief system to spread, it is subject to the laws of network diffusion (Katz & Shapiro, 1985). The more people have adopted a belief system, the more valuable it becomes for an individual user. This encourages further adoption as a form of virtuous cycle. Simplicity enhances diffusion – a complex system is most likely not adopted by a critical mass of people. “Critical mass” refers here to the number of people sharing the belief system needed for additional members to adopt a belief system. Although this may not be any single number since the utility functions controlling the adoption are not uniformly distributed among individuals; there is an underlying assumption that belief systems are social by nature. If not enough people adopt a belief system, it is not remarkable enough to drive human action at a meaningful scale.

5. Understanding. Belief systems are intangible and unobservable by any direct means, but they are “real” is social sense of the word. They are social objects or constructs that can be scrutinized by using proxies that reflect their existence. The best proxy for this purpose is language. Thus, belief systems can be understood by analyzing language. Language reveals how people think. The use of language (e.g., professional slang) reveals underlying shared assumptions of members adhering to a belief system. An objective examinator would be able to observe and record the members’ use of language, and construct a map of the key concepts and vocabulary, along with their interrelations and underlying assumptions. Through this proceduce, any belief system could be dissected to its fundamental constituents, after which the merits and potential dischords (e.g., biases) could be objectively discussed.

For example, startup enthusiasts talk about “customer development” and “going out of building” as new, revolutionary way of replacing market research, whereas marketing researchers might consider little novelty in these concepts and actually be able to list those and many more market research techniques that would potentially yield a better outcome.

6. Performance. By objective means, a certain belief system might not be superior to another either to be adopted or to perform better. In practice, a belief system can yield high performance rewards either due to 1) additional efficiency in communication, 2) randomity of it working better than other competing solutions, or 3) its heuristical properties that e.g. enhance decision-making speed and/or accuracy. Therefore, beliefs systems might not need to be theoretically optimal solutions to yield a practically useful outcome.

7. Changing belief system. Moreover, belief systems are often unconcious. Consider the capitalistic belief system, or socialist belief system. Both drive the thinking of individuals to an enormous extent. Once a belief system is adopted, it is difficult to learn away. Getting rid of a belief system requires considerable cognitive effort, a sort of re-programming. An individual needs to be aware of the properties and assumptions of his belief system, and then want to change them e.g. by for looking counter-evidence. It is a psychological process equivalent to learning or “unlearning”.

8. Conclusion. People operate based on belief systems. Belief systems can be understood by analyzing language. Language reveals how people think. The use of language (e.g., professional slang) reveals underlying shared assumptions of a belief system. Belief systems produce efficiency gains for communication but simultaneously hinder consideration of possibly better alternatives. A belief system needs to be simple enough to be useful, people readily absorb it and do not question the assumptions thereafter. Changing belief systems is possible but requires active effort for a period of time.

References

Katz, M. L., & Shapiro, C. (1985). Network Externalities, Competition, and Compatibility. The American Economic Review, 75(3), 424–440.

Simon, H. A. (1956). Rational choice and the structure of the environment. Psychological Review, 63(2), 129–38.

Joni

Why do I love startups?

english
Why do I love startups?

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.

Joni

Startup dilemmas: Feature priority problem

english

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.