Shoestring entrepreneur: I want to be a horse, not a unicorn

Remember my qualms about The Lean Startup; the assumption that the startup must aspire to rapid and massive growth. Here’s an interesting article that offers a slightly different view.

The siren call for many entrepreneurs isn’t money, it’s freedom. The freedom to chart your own path, the freedom to build what you want with the people you love. Taking money, building a board, and raising rounds takes away that freedom little by little. When you take venture money, you work for your investors, not yourself. You’re committing to grow fast to dominate your market and get your investors their cash back in the form of an exit or going public as soon as possible.

I was also interested to read about this alternative funding model from indie.vc

Despite sharply decreasing costs to start and scale technology based businesses, VCs continue to fund companies the same way they did 40 years ago.

And that way isn’t for everyone.

That way comes with a lot of expectations about the kind of company a founder wants to build. The kind of team a founder wants to recruit. The kind of exit a founder wants to see. And the kind of timelines a VC needs to see this all happen within.

There’s a mythology that entrepreneurs need to take VC money to hit the big time. While it’s true that some companies really do need outside capital, there are many examples of great companies that have reached revenues of hundreds of millions of dollars, or even gone public, without ever taking in capital, or taking it in only at a late stage, when they’d already created a high valuation by bootstrapping the company.

Perhaps there is a little moderation and common sense breaking out among tech startups?

[Unicorn image Creative Commons Share Alike Some rights reserved by Anley Piers]


Facebooktwittergoogle_plusredditpinterestlinkedinmail

Thoughts on The Lean Startup (Eric Ries)

I just finished reading the Eric Ries book, The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. I recall skimming this in Waterstones a few years back; I was surprised to find it was published as recently as 2011. Since then, it’s become a classic and many of its concepts, especially the Minimum Viable Product, have become ubiquitous in business life.

What’s this book all about?

Enterprises focus on developing new products efficiently, but what use is it to efficiently developing a product no-one needs? Today’s challenge is to build the right thing. Given the uncertainty, the unknowability, of the market, the only way to build the right thing is to test your ideas in the marketplace as early as possible. Push out a first offering and measure its uptake. Refine and repeat. Through a series of structured experiments, learn what customers value, and what will drive growth of your business.

Ries talks about a couple of leap-of-faith assumptions. These are the riskiest elements of a startup’s plan, therefore it’s a priority to test these hypotheses.

The first leap-of-faith assumption; the value hypothesis

A startup will only succeed if it offers something of value to its customers. This is equally true of for-profit businesses or not-for-profit social or governmental offerings. My current hobby project (definitely not planned as a for-profit startup) is a web site for travellers. The value hypothesis is:  “Travellers will find it useful and fun to track all of the UNESCO World Heritage Sites they have visited or plan to visit, hence they will be motivated to sign up and to return to the site.”

Ries would recommend building a very basic form of the the offering, in this case a web site. This is the Minimum Viable Product (MVP). The MVP will be primitive, it might even be buggy. But it provides a vehicle to test the value hypothesis. Early adopters are willing to endure rough edges if there is value in the offering. The imperative to learn quickly must trump the desire for perfection at this stage of an embryonic startup. Even small numbers of visitors can deliver insight into to customer experience; Ries described the early days of his company IMVU, which paid Google Adwords $5 a day to bring 100 customers to the site. Each week, the company would chart the behaviour of recent visitors, in terms of sign-up, login, usage, and conversion to a premium paid offering. Each week, new features would be introduced, and the team would monitor impact on the key metrics. This gave clear visibility of features which customers valued and should be retained, as opposed to features of no value, which were discarded as a waste of effort.

The second leap-of-faith assumption; the engine of growth

How does a startup grow? In one of three ways, says Ries: sticky, viral or paid. The engine of growth dictates which growth metric the entrepreneur should study most closely.

Sticky growth occurs when customers, once recruited, tend to stay with the product for a long period. This might be because of barriers to entry (such as market-leading technology), network effects (a special-interest community) or high obstacles to change (enterprise software). If your business depends on sticky growth, the key growth metric is attrition or churn rate. Even if you are attracting new customers at a high rate, growth will be meagre if existing customers are defecting.

Viral growth occurs when existing customers attract new customers through recommendation or word-of-mouth. The key growth metric is the viral coefficient, which is the number of additional customers who will use the product as a result of each new customer recruited. Businesses that seek viral growth must focus on this more than any other factor, because small changes will have dramatic effects on growth rate. A coefficient of 0.9 will lead to stagnation or failure, whereas a coefficient of 1.1 will lead to spectacular growth. As a result, such companies often do not charge customers directly, lest this impede viral spread, but instead rely on indirect revenue such as advertising.

Paid growth occurs when a business has strong visibility of the value it will extract from a customer over the lifetime of their relationship, and can therefore invest in marketing to attract customers. It matters not whether the Cost Per Acquisition (CPA) is $8 to acquire Lifetime Value (LTV) of $10, or CPA of $8,000 to acquire LTV of $10,000; both have a marginal profit of 20%, which is available to reinvest in further growth.

A fundamental assumption of this book I’m not sure about

There is an assumption that the startup must aspire to rapid and massive growth. Ries talks about:

The land of the living dead … when a company has achieved a modicum of success – just enough to stay alive – but is not living up to the expectations of founders and investors. Such companies are a terrible drain of human energy.

Prior to reading this, I would have confidently espoused my ambition to become a shoestring entrepreneur, building a web application or two that would appeal to a loyal, niche audience with no intention whatsoever of attracting venture funding, still less becoming the next Facebook. A digital corner shop if you will. But in Ries’s world, every corner shop should be dreaming of becoming the next Walmart. Caroline says it’s just because he’s American. I’m feeling a bit confused about this now; do I lack ambition? Is a small scale project doomed?

Things I really liked in this book

The book has a really strong focus on developing actionable metrics; Ries also calls this innovation accounting. I love to see simple measurements that illuminate exactly how a process is working. Unfortunately it’s a rare thing, and even the best-intentioned seem to create scattershot collections of what can I measure? that only serve to confuse. Ries further points out the danger of vanity metrics, which are less innocent. A management team determined to demonstrate success to investors can easily show flattering measures such as overall growth in number of customers, while ignoring or suppressing figures that may indicate growth is slowing, or attrition increasing, or new product features have not been valued by customers. They only delude themselves, and are likely discarding the vital information that could turn around their plight.

Specifically, I learned some techniques that I wish I’d known sooner and may be able to use in future. I’d heard all about A/B testing, but there were good examples of companies who build this into a rapid innovation pipeline such that no feature is complete until the A/B test results are in, and the decision is made whether to persist with it, or back it out as a failed experiment. I learned about cohort analysis, which would have been immensely valuable when I was trying to provide a clear representation of the marketing pipeline at Brighter Business, a complex situation with customers arriving online, sometimes obtaining quotes online, but generally converting via the call centre.

In regard to validated learning, the key phrase is Pivot or Persevere. Armed with the metrics that should provide crystal clear insight into how your product is performing, the entrepreneur has to decide whether optimising the current strategy will eventually deliver success, or whether a more radical change is needed. Pivot means changing course, while keeping one foot on the ground, for instance changing to a different engine of growth strategy, narrowing or expanding the product scope, or seeking a different customer group. I think for Ries, the difference between success and failure for a startup is the speed of reaching these decision points and the clinical accuracy of making the pivot or persevere decision.

Towards the end of the book, Ries introduces a discussion of small batch thinking, which absolutely appealed to me, and brings things back to the starting point of this blog; the inevitable failure of traditional Enterprise Architecture. The scenario is a father and daughters stuffing newsletters in envelopes. Father asks the children: what is the quickest way to address, stamp and stuff 100 newsletters in 100 envelopes? The daughters confidently say: first fold 100 newsletters, then stuff 100 newsletters into 100 envelopes, then address 100 envelopes, then attach 100 stamps. Father challenges them, and takes the opposite approach, fully processing one newsletter at a time, known in manufacturing as single-piece flow. Counter-intuitively, Father wins the race, and not just because he is an adult.

The advantages of single-piece flow have been consistently demonstrated. Part of the advantage arises because of tasks we tend to forget: in this case stacking and tidying the growing pile of 100 folded newsletters. But more significantly, the large batch approach is prone to unexpected rework. What if the folded newsletter doesn’t fit the envelope as we expected? We may have to go back and repeat work.

Enterprise IT, and specifically traditional Enterprise Architecture, takes upon itself the challenge of working out in advance all of the steps required to reach the target state. Then it tends to demand large quantities of cash to execute the plan. Lo and behold, things don’t go according to plan. The project’s stakeholders develop antagonism towards the project, and demand more frequent reviews. Productivity takes a dive as everyone spends their time talking about the problem rather than contributing to the solution.

How much better it would be if we tackled our transformation in small batches, with carefully chosen metrics, and rapid, iterative persevere or pivot decisions.


Facebooktwittergoogle_plusredditpinterestlinkedinmail

Three Things a City In Charge of its Destiny Ought to Know About Software

http://radar.oreilly.com/2015/01/four-short-links-9-january-2015.html

Photo City of Light (c) Carl Milner.

This quote gets to the heart of some of the mistaken group-think in enterprise IT.

The so-called economies of scale claimed for big IT solutions turn out to be largely illusory. Their business cases begin with wrong-headed, goods-dominant accounting copied from the world of manufacturing, where buying stuff in bulk really can be cheaper. Wishful thinking by people remote from the frontline carries these projects forward unchallenged. But by the time complex shared services have been tailored to the needs of the people and teams who use them, they can actually increase costs substantially.


Facebooktwittergoogle_plusredditpinterestlinkedinmail

Proud

Caroline pointed out that the last post was incoherent. I know what she means. Attempting to write spontaneously, it was blurt of mixed-up resentments laced with a few understated victories. Rather than return and straighten out that effort, I will unpick things and present a few short posts isolating some positive and negative thoughts.

What have I done these five years to make me feel proud? It’s been a team effort, but a few improvements to which I have leant my weight:

We adopted Red Hat Linux as default standard operating system. I arrived to a mix of Windows and IBM AIX. Nothing in particular wrong with Windows (it’s not my bag), but AIX was a liability. Application implementations were fraught with hard-to-find bugs. It became apparent that vendors such as Oracle and BMC placed AIX 4th or 5th in the pecking order for testing. Furthermore the IBM Power hardware was costly and headed for obsolescence. Linux allowed us to adopt commodity Intel-based hardware, and has been robust and well-supported by application vendors. Ubuntu or Centos might have been cheaper and braver choices, but would not have given the confidence of support by tier 1 application vendors.

We focused our application development effort on Java, specifically Pivotal’s Spring. The development team still has to support legacy Microsoft technologies, ASP and .NET, but they now have a focus on recruiting and developing the skill set for modern Java. Java developers are easier to find. The strategy has allowed them to progress into areas such as continuous delivery, and the rapid development framework Spring Boot. Again, there could have been cooler and braver choices (Ruby on Rails and its polyglot siblings) but, as much as I am tempted by the fast-moving, shiny toys, we are still an enterprise shop.

After a brief flirtation with MySQL, we have plumped for PostgreSQL as our non-Oracle database. Yes, we continue to use Oracle Enterprise Edition; we have no choice for many of the enterprise suites we (regrettably) are committed to. But we have placed a considerable bet on Postgres for some demanding bespoke applications.

And finally, in another bold move away from Oracle, we declined to pump a further £1m+ into Oracle SOA Suite and instead chose Red Hat JBoss Fuse. SOA Suite promised great things, but is the typical mega-vendor ‘kitchen sink’ middleware suite. I never had the sense that our developers understood it deeply. Furthermore, and the final straw, was that Oracle’s licensing prevented us from affordably deploying SOA Suite on our standard VMware infrastructure. We came close to creating an Oracle ‘ghetto’, a special purpose virtualised environment where Oracle software could be deployed without a many-fold increase in licence costs. But I couldn’t stomach it. JBoss Fuse is a packaging of Apache projects: ActiveMQ, Camel, CXF; with the commercial support the enterprise demands. It lacks the sophistication of the mega-vendor alternatives, but I view that as a positive. It allows us to treat integration as just another aspect of application development, with our Java team handling the complete task.


Facebooktwittergoogle_plusredditpinterestlinkedinmail

What’s the gripe about Enterprise IT?

This Enterprise Architect gig has kept me gainfully employed these past five years. So why turn on it?

I’m sitting in the auditorium of Gartner ITXPO, listening to Clean Bandit’s ‘Rather Be’. Superficially edgy, but ultimately tame. Grey-suited businessmen surround me (and yes they are men).

We are waiting to be told to embrace Bi-modal IT. The notion that it’s OK to let some aspects of IT implementation race ahead, agile-fashion, unencumbered by concerns of creating a chaotic legacy, with the associated high cost of ownership.

It’s progress of a kind. But this is 2014. When I joined The Firm as an Enterprise Architect in 2010, I encountered a sterile and deeply conservative landscape.

The strategy was “Buy Oracle”. Yes, we had a mission to tackle legacy. But the approach was to buy expensive mega-vendor packages, in the belief they must be best of breed, or better yet pre-integrated. No one ever got fired for buying IBM, right? They didn’t get fired, they just ran the company into the ground.

My mistake was to be too meek. I went along with this madness. Despite my hugely positive experiences implementing open source packages quickly and inexpensively for The Insurance Startup, I colluded with the Oracle strategy. Up to a point anyway. I recall making a stand with the IT Director to prefix the strategy “Why not Oracle?” with the words “In ERP”. It was a Pyrrhic victory. I was outnumbered by a conservative IT management team and forced to buy hugely expensive Oracle portal software. The implementation was horrible, the developers took against the programming model, we were forced by Oracle’s protectionist licensing to run on non-standard infrastructure, browser support lagged the industry. We are left with a million pound boat anchor.

On another occasion I spoke up for Linux, and a manager said “yee haw, the cowboys are coming!”.

We’ve made up lot of ground since then. The portal debacle was a turning point of sorts. Gradually it dawned that we were in hock to Oracle. Utterly objectionable licensing made it impossible to escape annual support charges, even for software we had never used, or found impossible to implement successfully.

I accept some responsibility for this. My role allows and expects me to lead the way. A braver soul would have decried the madness (but probably lost their head in the process, amid mutterings of “didn’t fit the culture”). A smarter corporate diplomat would have quietly challenged behind closed doors, and maybe won support bit-by-bit. My challenges were mild and inoffensive, we eventually changed course, Linux is is our default server platform, Oracle is regarded as public enemy number one, the CTO states in management meetings “we should use more open source software”.

The point is that this deep conservatism in Enterprise IT is anathema to me. It stems from management’s poor grasp of what the technology actually does, ruthlessly exploited by Enterprise vendors, who offer reassuring slogans but no real remedy. It has to cope with a community of lacklustre IT workers, who need hand holding. It clings to Enterprise Support as a fig leaf, of dubious real practical value when trouble strikes, but essential as a blame deflection mechanism.

I’ve clung on for nearly five years; the reasons, as I often joke, are “loyalty and stupidity”. In a candid chat with my boss this evening, he quoted a colleague who said “this company will suck the life out of you”. I crave an environment where effort-applied translates into progress-achieved, rather than being dulled by layers of management waffle and bluster. So I’m planning my exit… more later.


Facebooktwittergoogle_plusredditpinterestlinkedinmail

Plans and promises

I’ve no idea how long this will take; I’ve been a competent, dare I say, expert, developer in the past. Developing networking protocol stacks mainly, in C and C++. And then, in a diverse career, I’ve been a makeshift Unix/Linux systems administrator and infrastructure designer. But the chops are rusty. Besides some small-time dabbling in Python and JavaScript, it’s been 15 years since I programmed in earnest.

The plan is to acquire the basics of web application development. Spring seems to be a decent starting point; a balance of mainstream with ‘cool’. That opens the door to Groovy and Grails, which I’m drawn to without much knowledge.

At the same time I am keen to get to grips with Data Science. I have a smattering of relevant experience: A level statistics, machine learning and classification algorithms.

But I’m well aware of the danger of spreading myself too thinly. So let’s draw the line here.

[Image by @giuliaforsythe]


Facebooktwittergoogle_plusredditpinterestlinkedinmail