One of the inspirations for Analyst First is Eric Ries’ Lean Startup movement. One of Ries’ key distinctions is between different kinds of enterprise domain:

1. Known problem / known solution – e.g. engineering problems like building a bridge. Such problems are suited to traditional project planning and management because, fundamentally, the goals don’t change and the methods required to reach those goals are known, tried and tested. To be sure, there will be operational dependencies and contingencies to contend with along the way, but no radical unknowns. The appropriate KPIs here are those commonly used for project management: percentage complete, on time, and on budget against tasks and milestones in the context of a plan.
2. Known problem / unknown solution – e.g. many software projects. If the design can be specified upfront and is relatively stable then what remains unknown is the exact configuration of the working solution. The appropriate KPIs here are working lines of code, each of which gets the enterprise closer to its goal. Ries presents Agile software development as one way of managing this sort of enterprise.
3. Unknown problem / unknown solution – e.g. online startups. Here the viability of the enterprise itself is radically uncertain. The search is on both sides of the commercial equation: for customers with needs and products to meet them. Constant experimentation is required to iterate different offerings in search of a paying customer base, and this needs to happen as efficiently, effectively and adaptively as possible. Why spend 6 months building something no one wants when you could have learned that lesson in 6 weeks? This is the Lean Startup sweet spot.

The essence of Lean Startup is “pivoting“. Assumptions are identified in risk order and successively either validated or invalidated via experiments, each of which is designed to produce a learning outcome. Each outcome marks a knowledge consolidation point which determines the direction of the next experiment. “Lean” means running these experiments as parsimoniously as possible in terms of both execution cost and outcome. Why build the perfect website when you can get a Minimum Viable Product up much faster to validate whether people will use it? Why build a website at all initially if you’ve not first run a Google AdWords campaign to see whether prospective customers can find your landing page via search and are willing to click through to it? The leaner you are, the more pivots you can execute and the more you learn.

One of the core contentions of Analyst First is that Business Analytics lives more in the type 3 domain than in type 1 or 2. As such our approach advocates:

1. Accepting uncertainty, sometimes radical uncertainty.
2. Treating learning as an outcome, often the primary and explicit outcome.
3. Seeking validation where possible, as opposed to making ‘faith-based’ decisions.