The Lean Startup and Schopenhauer’s Pessimism


There’s a lot of same in Eric Ries’ and Arthur Schopenhauer’s thinking. The first one has become rich by creating a virtual reality chat service (IMVU) and has written a bestseller on running successful startups (Ries, 2011, The Lean Startup). The second one was a classical philosopher lived 19th century, who abandoned merchant carrier in his father successful company and became famous of his pessimism. At first sight, they appear very different kind of thinkers. However, there is surprisingly much common between them – and a crucial difference.

Ries is puzzled by question, why so many startups fails even if they have marvelous strategy and clever people running them – and even if the customers have said that this is exactly what they want?

Schopenhauer struggles with more general question. Why is the world filled with frustration and pain, even if we were able get what we want? Essentially they seem to reflect the very same phenomenon, satisfaction as the distance between desire and actualization.

The clever and capable people fail to get what they really want, because they are deluded to think wrong thing worthy. So to say, once they realize that the red and big apple is rotten inside it’s often too late. Schopenhauer talks of self-satisfaction. Ries focus on customer satisfaction. Yes, different domains but still the same mechanisms.

Impurity of goals/Will

For Schopenhauer the foundation of frustration and pain is impurity of our Will. There is a way to achieve a more tranquil state of consciousness, aesthetic perception. In this form of perception we lose ourselves in the object, forget about our individuality, and become the clear mirror of the object. (By the way, if you narrow the definition by replacing “object” by “task”, there is obvious resemblance to flow experiences.)

For Ries the foundation of the customer dissatisfaction is impurity of the goals. There is a way to achieve a more profound and clear conception of goals and needs, the minimal viable product combined with quick feedback loop allowed by short cycle time. The minimal viable product consists of only the absolutely necessary features needed to achieve the “pure” goal.

Schopenhauer studies how to make ourselves more apt to the joyful and tranquil flow by delimiting disturbing, unnecessary desires. Ries tries to develop principles to make the object-in-itself (product or service as something purely useful or otherwise delightful) more desirable because of the correct reasons and for the correct consequences.

Schopenhauer praises artistic geniuses and sees their work as salvation – musician geniuses especially. Ries praises entrepreneur geniuses and sees their insight the best possible way to make world better, not only in business but in every area of life where people “create new products and services under extreme uncertainty”. In short, for them both the most worthy job is to create new clarity and conceptual unity out of the chaotic world. They both have similar existentialist stance even if there is a differences in emphases: Ries focus on materialized forms of clarity and unity while Schopenhauer look after more transcendental ones.

Analysis paralysis and distrust in rationalism

They both struggle with the analysis paralysis and the overly sound trust in rationalism. For Schopenhauer the world is primarily product of will and secondary saw as more rational manners. Ries expresses his arationalistic approach as follows:

“There are two ever-present dangers when entrepreneurs conduct marker research and talk to customer. Followers of just-do-it school of entrepreneurship are impatient to get started and don’t spent time analyzing their strategy. They’d rather start building immediately, often after just a few cursory customer conversations. Unfortunately, because customers don’t really know what they want, it’s easy for these entrepreneurs to delude themselves that they are on the right path.

Other entrepreneurs can fall victim to analysis paralysis endlessly refining their plans. In this case talking to customers, reading research reports, and whiteboard strategizing are all equally unhelpful. The problem with most entrepreneurs’ plans is generally not that they don’t follow sound strategic principles but that the facts upon which they are based on are wrong. […H]ow do entrepreneur know when to stop analyzing, and start building. The answer is a concept called minimum viable product.” (Ries, 2011, pp. 90-91.)

In Ries thinking, the facts that are wrong seem to have a similar root cause than the frustration and pain have in Schopenhauer’s philosophy: they are rather consequences of our individual whims and biases than the Platonic object-in-itself. Schopenhauer and Ries are both (transcendental) idealists in this: they both seem to think that somewhere out there is the pure essence of things (the idea of a thing) even if the essence never fully apparent to us.

Scientific method vs. asceticism

The crucial difference is how they but their insight into practices. Schopenhauer chooses esoteric asceticism and the denial of will-of-life. Ries chooses scientific method:

“Despite the volumes written on business strategy, the key attributes of business leaders, and ways to identify the next big thing, innovators still struggle to bring their ides to life. This was the frustration that led us to try a radical new approach at IMVU [Ries’ first truly successful startup], one characterized by an extremely fast cycle time, a focus on what customer want (without asking them), and a scientific approach to decision making.” (Ries 2011, pp. 4-5.)

I’d like to underline here “what customer want (without asking them)”. An assumption behind this is similar to an insight beyond Schopenhauer’s pessimism: What customers say desirable is unlikely the exactly same thing than the one what makes them happy and willing to use the product. The second assumption is that the scientific method is the most workable (known) way to get over this obfuscation of introspection.

Don’t understand this wrong! Ries never suggest that we shouldn’t listen customers! Quite the opposite, rather we should observe how they really behave, think and feel in more general terms. We should listen more than theirs words – and not only listen but also extrapolate. Talking is just one form of behavior and it conveys some information. There are others that works sometimes better. E.g. are customers, in fact, willing to pay for your service or product and how they actually use it? Are they more wiling we do the change A rather than B?

Actionable metrics vs. vanity metrics

[Be aware: that I will next slightly strengthen the Ries’ argument! Even if I truly like Ries’ The lean startup, it does not follow its arguments to the end. I will emphasis here strongly the value of falsifiability, while for Ries’ emphasises more the value of quick validation of hypothesis.]

No matter what indicator and metrics you use, the main objective should be the proof of your hypotheses by attempting restlessly falsify them.

Attempt to falsify hypotheses is a crucial difference to the ordinary (product/service) design and strategic planning (and other similar domains of knowledge). Usually, neither the design nor the strategic planning is done by truly attempting to falsify the vision as a part of the process. They are rather done in order to find a vision and a solid strategy to proceed toward success in marketplace.

By underlining the importance of the quick validation of hypotheses, Ries ends up a rather new way to define metrics for progress. Metrics should not be defined against goals but against hypotheses. That is, you should not define a growth target but rather a metrics that indicates if your hypotheses of the (used) growth mechanisms are correct. If you define the all metrics against a set of goals, you cannot deduce if the goals were correct or if they should be adjusted. In addition if the metrics looks bad, you don’t know how to react. If an indicator shows that one of your hypotheses was wrong, you know immediately what to do: Adjust the hypothesis – and the strategy accordingly.

Thus, purpose of metrics is not to validate if we are going toward the goal but to alert if we need to change something. This is what Ries’ means by saying that metrics should be actionable. An opposite for actionable metric is vanity metric. Vanity metrics are dangerous as they may affirm false assumption and create feeling of false security.


Consider following example (that could be from my work): A new intranet was launched in the beginning of year. Management believes that the launch was a big success, employees finds the intranet annoying and feel that they need to waste a lot of their time to get things done in the intranet. There were two key metrics management followed closely: Ratio between active and passive users and visits to the front page. On Q1 ratio between active and passive users was 0.5 and on Q2 and Q3 it is 0.4 and 0.7. In Q1 there was 10 000 unique visits to intranet front page followed by 9 000 and 14 000 in Q2 and Q3. Was there a problem?

In Q2 things looked bad, something need to be done in order to overcome the resistance. Thus, between Q2 and Q3 IT closed file shares and now there’s no other way to get things done but to use the intranet. As a consequence the change eventually happened and in Q3 the number looked great, didn’t it? Uh, not quite. Obviously, there is no good reason to think that after people learned to use intranet they eventually adopted it, and now find it highly useful. But the numbers looks good. The initial exuberance was followed by a chaos and disillusionment and then, eventually, the adaptation. Wasn’t this just like in any change, was it?

In this case, however,the people probably use intranet just because they have no alternative anymore; they use it more just because they cannot use it less. This was not quite the goal, but according the metrics everything looks good. The management didn’t truly attempt to falsify their assumption that this is a beneficial change for workers. Actually, they didn’t explicitly postulate that assumption – perhaps it was too obvious. Thus, the need for the change of direction is not apparent and now there is a waste generator in the middle of communication and work. It would have be more relevant be to measure if workers actually get things done faster/better.


Sometimes listening carefully what customers say is enough. That is rarely the situation when developing new products and services. Observing how they, in fact, behave, feel and think is far more important. In order to do that properly you need a good hypothesis and serious attempts to falsify your theory. If you hypothesis was false (which is rather common) it’s time to pivot and take another direction with different hypothesis of success. That is the beef of Ries’ “The Lean Startup” – at least for me. Overall estimate: 4/5.

And what comes to Schopenhauer, I’d like to add the scientific method into his pessimism. Without the scientific method Schopenhauer pessimism is far too naïve and distressing for my taste. This is it in nutshell: (1) Create hypothesis of your desires. (2) Experiment. (3) Spy your behavior, feelings and thinking in order to falsify the original theory. Finally, (4) correct the original hypothesis accordingly if needed. Repeat. It’s not that important what you originally thought desirable. Rather, you should keep on experimenting your desires so that they match better with your behavior, feelings and thoughts.


Book review: Continuous integration in .NET.

I’ve been lazy to write anything here. I’ll try to write more from now on.

I’ve been reading quite many books lately, and I have even completed few of them. Thus I’ve set myself a goal: write a review on all software related books I’ve read (or almost read) during the last year. Here you have the first review:

Marcin Kawalerowicz and Craig Berntson (2011): Continuous integration in .NET


Overall estimate: 4/5. Good overview on the topic but doesn’t dive deep into the background and the theory.

The authors start and end by summarizing the idea of continuous integration. They won’t go deep in the theory or the motivation to do continuous integration. It ‘s okey as the main goal of the book seems to be to write good overview on how to implement continuous integration in .NET. The authors also succeed in that. Book introduces tens of different tools. Many of the tools I knew and had used already, but there were few new ones. They also succeeded to deepen my knowledge on some of the tools.

Since the overview of various different tools is the best part of the books, here you have listing of tools and areas of continuous integration with my personal short comments. (If the concept of ‘continuous integration’ (abbr. CI) is new to you, please check the basics from Wikipedia. I chose to be lazy and not explain them.)

(1) Source code repository. The authors discuss mostly SVN and TFVC (Team Foundation Server version control). Before the chapter on the source control tools, they the point out the significance of properly organized source code and the tools for CI. They mention distributed version control systems (DVCS) like Git but find DVCS systems a bit more difficult form CI point of view.

Personally, personally I’m really glad that now Git is now fully supported in Visual studio and TFS. (Or actually, not quite yet: you have to install Visual Studio 2012 Update 2 CTP (Community technology preview). So, you still need to wait for RTM versions, if you don’t want to use beta. In addition, Git is not yet available for in-premises installation of TFS.) 

I see distributed version control systems as an big opportunity e.g. in following cases: (1) simultaneous and geographically distributed maintenance of released code and development of new features and (2) multi-vendor environments. Of course, you have to do design decisions you need not do with centralized system – and, yes, DVCS it is slightly more difficult concept than centralized version control system. Great power comes with great responsibility.

(2) Build process. According the authors MSBuild is superior tool, however, they shortly discuss NAnt also. I haven’t ever used NAnt, but it’s easy to believe that MSBuild is better. By the way, I was not aware of MSBuild Community Task project. E.g. build task that zips certain files as a part of build sounds good.

(3) Build server and build agents. The book compares nicely Team Foundation Server, CruiseControl.NET and TeamCity. I’ve used CC.NET in one project and TFS in several. However, TeamCity is definitely something I need to study more. The main reason is following: if not everyone using build servers and version control have MSDN Professional/Premium/Ultimate subscription TFS is rather expensive (as far as I know).

Also the tool you need to use to modify the TFS build process is – well, not that good. Guys who designed TFS build workflow user interface should check out how neatly SQL Server Integration Services (SSIS) visualizes the workflows. Yes, I know that TFS uses Windows Workflow Foundation but that’s no excuse: if workflow is poorly visualized and the designer is difficult to use, the workflow is poorly visualized and the designer difficult to use; the workflow framework makes it no better. SSIS is good example that it need not be so.

(4) Test automation. Following tools were discussed: NUnit, MSTest, White, Selenium, FitNess, Visual Studio inbuilt UI test framework. Unfortunately, currently the biggest pain I have with unit testing relates faking framework APIs with acceptable amount of work.

(5)Statistic code analysis. The tools: FXCop, StyleCop, NDepend and TeamCity code analysis tool.

As a side note: Learning is the main challenge in software industry. The tools listed here may and – and in some extend – will accelerate learning, but automating code analysis and relying on only it, is not enough. The code must make sense within the problem domain, and no tool can ensure that. The danger I see here, is more or less the same than with the “best practices”. If you don’t understand the problem, focus in it, and keep it simple, the formally perfect code is worth of nothing. The “best practices” are not the goal nor are they the staring point, they should be seen as initial but potentially obsolete baseline and never anything more. Thus, always seek for something better and simpler. The same applies to these tools. Probably, no-one claims that automated statistic code analysis is enough. No-one claims that they are bad either. They are good as long as you understand what they are able to do and what not. I just wanted to underline the limits of automation on this area.

(6) Documentation generation. Just one tool was covered: Sandcastle.

Personally I’m slightly skeptical on the usefulness of XML documentation, since you easily end up having more comment than code (or comment that add no value) and thus code readability is severed. I’m waiting for a great, out-of-the-box innovation on the area of code documentation. If anyone happen to know a visual studio plugin that automatically hides XML documentation but let me easily check and write them when needed, please, let me know.

With no doubt, the code need to be well documented. However, XML documentation is a good solution only if you need not write, read and maintain code yourself. Otherwise they are too verbose and distracting. The smallest possible improvement to this: Chance XML documentation so that they could be placed also at the beginning or the end of method body like in PowerShell v.2. The goal: once you collapse the method also the XML documentation would be hidden.

Currently, I’m seeking the answer from BDD (or something alike): You first write description and examples for you APIs in more or less behavior driven way. The API’s behavior description and the examples will compile into the abstraction layers (abstract base classes and interfaces + something more like enums and constants) and test containers. Then your write the tests and the code (side by side). In theory, F#’s custom type provider could do that job but that’s completely different story.

(7) Deploying code. In the book, Microsoft Installer (incl. WiX and ClickOnce) and MSDeploy were covered. I definitely need to learn to use MSDeploy better than I currently do.

(8) Continuous integration with databases. Authors start by RoundhousE and end up praising Visual studio in-build database tools.

I have used some of Visual Studios database tools in small scale demos only and they seem to be good. However they won’t make databases open for extensions and closed for modifications (Strictly speaking, you cannot apply principles of object oriented programming to databases, but you get the idea). So, the root cause that makes SQL-database CI difficult and laborious remains.

Anyway, if I needed to develop software with extensive custom database Visual Studio in build tools would be my initial choice.


As I mentioned, they won’t go deep. I.e. if you are expecting solid arguments you can use to justify build automation to customer or management, choose another book. Unfortunately, you cannot either find proper references literacy discussing the subject more deeply. This book is good starter and overview on the subject, that’s all. Actually, let me correct myself a bit, it is also well written and edited overview and starter.