We can see our forests vanishing, our water-powers going to waste, our soil being carried by floods into the sea; and the end of our coal and our iron is in sight. But our larger wastes of human effort, which go on every day through such of our acts as are blundering, ill-directed, or inefficient, and <redacted> are less visible, less tangible, and are but vaguely appreciated. We can see and feel the waste of material things. Awkward, inefficient, or ill-directed movements of men <or women>, however, leave nothing visible or tangible behind them.

This could be a quote written a week ago, but it was written in 1919 by Frederick Winslow Taylor in his management book of the century The Principles of Scientific Management.

A lot has been said about Taylor’s book that eventually led to the movement of Taylorism. The most commonly held indictment is that it was mechanistic thinking, taken in an era of solely mechanical manufacturing and no longer applies to the modern world.

Winston Royce also wrote an article about software development, citing that a linear approach to development, aka waterfall, would be the wrong approach. Readers misread or misunderstood this leading to a world of in appropriate application of techniques and patterns.

Whilst Taylor’s belief systems in the book may be held up to scrutiny today, like Royce, Taylor’s work has been misinterpreted and vilified by those pushing modern management methods*.

This blog post will discover where Taylor’s Principles of Scientific Management aligns with current modern management thinking, where it is in stark contrast and the grey zones that need further discussion.

Aligned with modern thinking

The following concepts described within The Principles of Scientific Management are aligned with modern management methods:

• It is important to ensure that individuals are suitably trained to be competent for their job. This should be considered over hiring in skills.
• Competency is not just people contributing value to the product or service but also leaders.
• To have a prosperous organization, you have to have prosperous people.
• People need to be paid a fair wage (also noted as a first pillar of motivation and a basic human right in Dan Pink’s book Drive)
• Managers know that the collective wisdom of those underneath them far exceeds their own wisdom. Because of this, managers are best placed to provide a clear problem and then steer clear of going into solutions.
• Management is a co-operative activity, managers should guide, done daily, but even if guiding should be partly accountable for the outcome. Managers should not direct or coerce.
• The importance of customer is a critical third pillar of any organization – employer, employee and customer need to be considered together.
• There are no silver bullets for solving organizational problems.
• Inefficiencies are most often due to the system.
• Time and motion studies should be utilised to assess and remove waste or simplify steps. The modern take on “time and motion studies” is value stream mapping and optimization.
  One of the bigger challenges that people have to applying Lean in Software Delivery is that removing waste doesn’t apply to knowledge work and that it is best applied to manufacturing. Whilst it certainly cannot be denied that Lean excels in a manufacturing environment, waste does exist in knowledge work. For example, in software development, if you are running too many branches at once then you have merge motion that multiplies out. Another example is unstable development teams, which result in knowledge waste.
• “Sweat shop” conditions don’t make for an effective organization. Sustainable pace of delivery is important to flow and optimal value output. This means having breaks and suitable working hours.
• Productivity, that can result in a competitive advantage, is obtained through efficient usage of both humans and importantly machines/automation
• Some methods/techniques are better than others for specific problems. A large toolbox is valuable and knowing what the right tool to use for the situation is important. Use real data to give insight to what tools work best in what circumstances.
• Run experiments to find what works more effectively, this is especially true when the problem to be solved is complex.
• Quality over speed is never an acceptable trade off. Quality needs to be kept high in parallel to improvements in efficiency.

As you can see from the points above, Taylor’s Principles of Scientific Management aligns quite heavily with Lean and to some extent the works of Agile, Systems Thinking, David Marquet’s Competency model and Lean Startup.

Unaligned with modern thinking

With the movement of time, however, there interestingly has been a cyclic return to concepts that Taylor is directly advocating against. These include:

• Management is a true science with clear laws, rules and principles. Scientific management is applicable to all kinds of human activities.

The Principles of Scientific Management sometimes also refers to itself as a Task Management approach. It was brought about in the industrial age and was dealing with human to machine interaction. Whilst the world back then was typically a heavily physical interaction, now days it is more of an intellectual interaction where the machine is the conduit for activity between individuals through human built programs. The statement above is why Taylorism gets labelled as “mechanistic thinking” rather than “ecosystem thinking” but it is not surprising when the problems that were being dealt with back then were either simple or complicated.

Most work place environments are complex where the laws, rules and principles are spread out over so many sub-systems of management and are often conflicting with what was the original intent behind the Principles of Scientific Management – that of an efficient individual producing quality output. We have gone awry with controls and convoluted value streams and should seek to first simplify. This isn’t to say that all things complex can be simplified down to a complicated or simple space of problems, but that there is still a lot of simplification opportunities out there, though getting management to a stage of science is probably an unlikely goal and dismissive of the human element. Enforced standardization for everything is not the answer, but in some cases some standardization may be beneficial and in other cases removal of standardization may be beneficial – the point is, you need to understand the problem space you are dealing with and the impact that standardization (or lack of) is having.

Scientific management doesn’t work in complex environments where the best outcome is non deterministic. That said, scientific management also concedes that in complex spaces, an experiment approach should be taken to find the more of the successful patterns to implement. This is not unlike a ‘Probe-Sense-Respond’ approach that Agile utilises.

• People have a natural instinct and tendency to loaf

This is certainly a divisive statement. Those people familiar with the Theory X vs Y work will recognise this statement as coming from a Theory X leader, that is, someone who is naturally pessimistic about their people, thinking of them as unmotivated and needing constant direction.

Taylor goes on to say that systematic “soldiering” (underworking) is intentionally done to keep employers ignorant of how fast work can be done. It is in each person’s self interest to not work faster than anyone has in the past before. They work as slowly as they dare.

Whilst these are certainly shocking statements, one thing of note however is that there has been a growth of science to back up some of the statements made in the area of social loafing. This is not the say that the solution to the problem should be command and control management and standardization, but interestingly the transformation approach within the Principles of Scientific Management actually had the answer – to separate the team and one by one reform a higher standard, re-integrating individuals one by one to negate the chance of social loafing. Taylor’s approach also made it clear that each individual’s contribution would be assessed and rewarded as an individual over as a team to ensure performance. Interestingly, these are two of the steps to combat social loafing.

But how does modern management approaches deal with social loafing? Agile tries to keep people accountable through setting regular small goals and helping to support the team to achieve them on a daily basis. I was once a Scrum Master in a team where one person in the team was underperforming. It was obvious to everyone in the team (including the individual involved). The person actively opted to exit the team citing that they knew they couldn’t keep up and didn’t think any level of support would get them to that state. This is exactly what is described in the book – that not all individuals are cut out for all work and even despite support and training, sometimes they should just find something better suited to them. This individual went onto a production support team and continued to perform well and happily. The more horrible version of this is the opposite effect. I was once in a job where I was pulled aside by my manager. They said, “I have had a few comments about your performance. You seem to be going fast against everyone around you. We need you to slow down the pace of your work.” It wasn’t that I was conceptually ahead of everyone, it was that I was literally putting too much output out and getting complaints because of it. I discovered that if I stopped work at 11am each day I met the pace of everyone else around me. I was forced to loaf at the pace of others so they didn’t feel bad about themselves. Acceptable performance rates are defined by the norms of the majority. I really don’t think anyone has a great solution to this problem yet.

• People need to be financially incentivised or incentivised for a promotion to work more effectively

Dan Pink’s ‘Drive’ book and the studies referenced within highlight that people need basic rights incentivisation to be motivated to work, but that extrinsic rewards like bonuses do not work in knowledge work environments. ‘Drive’ does note that this works for simple problems, especially manual problems so it isn’t surprising that Taylor came to the conclusion that bonuses are an effective way to motivate individuals, but it is clearly a statement that doesn’t work for problems requiring human thinking. Some organizations are already taking the step to remove bonus systems not just because of this but because of the time effort invested in it and because of the conflicting environment it creates. It should be noted that when Taylor talks about incentivization, he specifically says that quarterly or yearly bonuses are not the solution and are not frequent enough to make an impact on behaviour. So whether you take Taylor’s opinion or Dan Pink’s, the point is neither of them are advocating for quarterly or yearly bonuses that 90% of the corporations still use.

• Hard work can only be achieved through uniform process definition and adherence.

Again, we now know that motivation has a huge factor on performance and hard work and that mastery, autonomy and purpose play a huge hand in intrinsically motivating individuals. This is not to say that process is bad, but intrinsic motivation is the trump card. Those who follow Agile believe in “individuals and interactions” over “processes and tools” because it is through motivated an connected teams that delivery teams best succeed. If you have to deliver work as a team, then you need to be a team and no process is going to solve deeply personal issues between two individuals.

• People cannot train or learn by themselves. A manager’s job is to define the process and train others.

People want to improve. They want to solve problems and get better as a person with a trade/craft. Forcing only one way of learning on them is quite limiting by today’s standards and again Dan Pink’s “Drive” book describes the importance of self-discovery of better ways of working to being a significant enabler to intrinsic motivation. Taylor made this statement because of the complexity of knowing the better way being unobvious to most people. In fact, they recommended getting the highest performers together and studying them to find the patterns of performance to find a new value stream. Experiments were run and then the value stream was further tweaked through constant refinement. Logic wise, it is hard to argue with the approach – amplify the patterns that are working. This is actually what happens in Agile as teams share patterns of success with others.

The step wrong that Taylor made was in thinking that there was no way to self-organize to find these patterns themselves. Modern management methods have just given us a set of tools for individuals in teams to share patterns and learn from each other without managers having to be involved in the process. That said, Lean strongly advocates for “Leaders as teachers”, is this very different?

• Management take over all the work that they are better suited to, specifically this includes all the work plan to deliver against (activities, and timeframes).

I have seen a manager once create a project plan for their team of fifty people to deliver it to. They did it overnight with their buddy. You can imagine how horrible that plan was. The project that ran against that plan was seven months late and twenty-five million over budget. Nothing ever runs to plan which is why in Agile the belief is “Responding to change over following a plan.”A plan is important, a plan that is responsive is better, a plan that is made with the people who are doing the work is best. If you don’t include people in on designing and adaptations of the plan then they don’t feel accountable for the outcomes.

• Principles of Scientific Management is all about individual goals and individual tasks.

It does this because it believes it is the most fair approach for people and organizations. It believes that herding and working as a gang is a bad thing (most likely due concerns to loafing) . This is probably acceptable for simple problems but for a complex problem where multiple specialists are required we need to find ways in modern organizations to have teams working successfully together. Because of the heavy focus on individual tasks, it could be said that Scientific Management seeks only resource efficiency and not flow efficiency like Lean does, but I think it is less about individual utilization and more about simplifying everything down to single piece, single person flow.

• Lastly, and probably most importantly, the Principles of Scientific Management is incredibly disrespectful in a number of instances to human beings. With comments like workers being stupid or idiots and “you do what you are told to do, when I tell you to do it, and don’t talk back”, it stinks of Theory X command and control attitudes. Respect for human beings is a significant pillar in most modern management methods.

Taylor’s writing is symptomatic of the era and time that it was written in – it faced problems that are different to ones organizations are facing today with attitudes that would easily get you fired by today’s standards. But everything isn’t rosy or wrong, so let’s take a look at the perspectives that need more discussion.

Could go either way

The following perspectives from the Principles of Scientific Management are worth discussing further:

• Underworking (deliberately working slowly to avoid doing a full day’s work) is the greatest evil.

Loafing is just one element of underworking. The more common type of underworking I see is apathy, where people either don’t care about what they do or are unengaged. The causes for this are simple, but solving it is less easy.

Firstly the purpose of the work could be disconnected from how a person perceives it, for example, an employee cannot see link to activities to the bigger goal, or they don’t believe in bigger goal, or their activities or the goal changed from when initially brought on board. Secondly, it is possible that there are interactions at work that have led them to feeling disconnected – either through struggles with other people or struggle with the system that they are doing work in. Thirdly, sometimes people have so much going on in their real life outside of work they just don’t have the cognitive space to give everything to their job during working hours. Whatever the reason, none of these should be considered “evil” attitudes.

• Managers should plan at least one day in advance, with written instructions, describing the detail of the task to be accomplished.

Detailed task instructions is pretty ridiculous in today’s modern corporation. A more modern approach is to set a clear goal and outcome and give people the space and support to get there themselves. What I do find interesting about this statement is the “at least one day in advance” bit. This suggests that Taylor’s take is that plans can be quite rapidly adjusted and just in time based. In Agile, teams plan in Sprints that are a week or up to four weeks planned in advance. Teams also do Daily Standups which is intents of a plan for the day for each individual (though this isn’t the key intent of a Standup).

• You should train and transition people into new ways of working by having an individually tailored approach, creating a new target state one person at a time.

This was one of the more intriguing statements to me. When we transition people into new ways of working, yes there is individual coaching, but we also tend to transition whole teams. It reminded me a little of the Monkey and Banana Syndrome, where a new norm is established one person at a time with little explicit expectation setting on how you are manipulating the people. It is important whenever you introduce new ways of working with people or teams that it is something that they want to try, but also, that the reason why is made clear to all involved.

Conclusion

It is not uncommon to hear from people implementing new ways of working statements like “That’s not Agile” or “That’s not Lean”. In a similar manner, the Principles of Scientific Management has equally suffered from poor application and consequently received a worse image than it probably deserves (Theory X style language aside). In a similar vein, Taylor also conceded that a transformation wasn’t a quick solution, but a multi-year journey, acknowledging that the human change element was one that would take the longest time. Interestingly, Taylor also recognized that transformations often took a pattern of being easier once one quarter to one third of the organization had made the change – this is more commonly referred to as crossing the chasm.

But has Taylor’s Principles of Scientific Management helped us or hindered us? The fact that so many of the beliefs are still valid suggests that it has been helping us, but I can’t help but think of the opening statement, that was Taylor’s cry for change, remains unresolved – our forests are still vanishing, our waters going to waste, the end of oil is certainly in sight. We still have people blundering, inefficiently working, often with little appreciation. The question is, is Agile and Lean or any other modern management method getting us further along – probably yes, and with more respect and connections to humanity, but not fast enough.

* Note: Whilst ‘Modern Management methods” is quite a broad generalization, for the purpose of clarity it includes the work from approaches, frameworks and concepts from Agile, Lean, Lean Startup, Design Thinking, Dan Pink’s Drive, Complexity thinking eg Cynefin/VUCA, David Marquet’s Turn the Ship Around, and Systems Thinking.

Arya Stark – Stick bad ideas with the pointy end

This is a PO take on Arya’s statement “Stick em’ with the pointy end” referring to her high prowess and knowledge on how to wield her sword ‘needle’.

The Product Owner rule here is to stop starting work if it doesn’t hit the mark from a analytics and validated learnings perspective. We’ve all seen the HIPPO (HIghest Paid Person’s Opinion) effect in action – work that we know shouldn’t go ahead that seems to be fast-tracked. The best Product Owners are ones that are unafraid to terminate work when it is a bad idea, knowing the risks that it may have to their job but holding steadfast regardless.

Ygritte – You  know nothing without validating your hypotheses

Whilst Jon Snow arguably knew nothing according to Ygritte, so too do teams and Product Owners if they blindly go building capabilities without validating problem-market and problem-solution fit assumptions.

Lean Startup gave us a huge shift in the mindset of software development when it began to re-wire our thinking to stop considering everything a requirement and to start to test and learn on our riskiest assumptions.

Great Product Owners not only test and learn on their riskiest assumptions around problem-market and problem-solution fit, but they are critically aware of the different types of cognitive bias and actively struggle against their better-self in order to ensure that the best possible solution goes to market.

Jon Snow – Benefits are coming

It might as well be winter with how much money is spent building work that doesn’t result in the expected benefits. Although most people have heard the of the 2002 Standish Chaos report that cites 64% of features are rarely or never used, this has yet to be considered statistically valid. Again the biggest challenge to how products deliver benefits has come from the Lean Startup community by focusing on a lifecycle that deeply embeds into its core a process of Build-Measure-Learn with critical decision points at the “Learn” stage to pivot (changing problem goals), persevere (continuing on same path, changing solution options) or perish (stop the work altogether).

There is still too much “throw it over the wall and it’s done” mentality in the industry. Leading organisations are deeply embedding this learning cycle into their development approaches and moving away from heavy batch to more flow based lifecycles. Whilst the Scaled Agile Framework (SAFe) is continuing to grow momentum, it is lost on many that implement it, that applied poorly, it creates massive three month batching.

Think about what this means from a test and learn perspective – you release something to market and begin to gather analytics and data. At the same time you start your next Program Increment meeting and create a firm commitment for the next three months of work. Let’s say that after three weeks you get enough data to validate what you just released and with great concern it just isn’t resulting in the outcome expected. You have an assumption about what you need to pivot, but it will require two weeks of work. What do you do?

You can wait to the next Program Increment, which is another two and a half months away, and then deliver a change in another three months (just over a five month pivot – yikes!). You could pull something out of the Program Increment, thus breaking the expectation that was set, further delaying the scoped benefits. If you were smart you would have built in some slack into the Program Increment to allow for pivots on released work.

In the field, I have rarely seen either of these decisions occur. Leaders don’t generally allow any slack in a Program Increment and instead tend to drive for the whole increment to be filled up, and then sadly what happens next is they push to have the teams deliver both, breaking their sustainability with a promise of “we won’t let this happen again”, which it inevitably always does.

Whilst you could argue that these leaders haven’t been coached effectively and are misunderstanding the core Agile manifesto value around adaptation for Agile (responding to change over following a plan), it doesn’t deminish the fact that SAFe as it tends to be implemented results in massive batching which in turn reduces the time to benefits and pivoting for benefits optimisation.

Great Product Owners know this and will be empowered to push back against the organisation’s leaders to ensure benefits optimisation. To do this, again the Product Owner will likely need great courage to fend their decision against leaders within the organisation.

Littlefinger – Backlogs aren’t a pit, backlogs are a ladder

For a while I considered using the Petyr Baelish quote “Fight every battle everywhere, always, in your mind. Everyone is your enemy, everyone is your friend. Every possible series of events is happening all at once” twisting it into a quote about stakeholders, customers and predictability of needs, but in the end I used the more known quote, “Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. And some, are given a chance to climb. They refuse, they cling to the realm, or the gods, or love. Illusions. Only the ladder is real. The climb is all there is.”

Backlogs are real. The climbing through them to deliver is (almost) all there is. Importantly a backlog shouldn’t be a pit. Product Owners tend to acknowledge all requests from stakeholders and politely put them into the backlog. These get prioritised down at the bottom of the backlog and languish for all of eternity. Great Product Owners will look at not just the important and prioritised work in the backlog as part of backlog refinement, but will also actively remove aged items within it, work that will never get done because it is deemed as too low in priority or value.

Product Owners will also appreciate where they are in the Explore-Expand-Extract stage of their product development and their backlog’s content will be reflective of the stage.

Tyrion – A Lannister always prioritises by value

Need I say more? The answer should be yes. A good Product Owner will prioritise by value, a great product owner will prioritise by value with an understanding of cost, alignment to strategy, market and competitive trends. Value can take many forms – customer value, business value, risk reduction or meeting industry obligations. Balancing value with cost of delay and job size will mean Product Owners can realise benefits sooner. A weighted shortest job first algorithm with relative estimation can be utilised to compare work in the backlog in order to ensure that the highest valuable work is prioritised higher.

Daenerys – I’m not just going to tell the story, I’m going to live the story

Daenerys Targaryen may be the breaker of chains with a goal to break the wheel, but as a Product Owner she epitomises the role of a story teller. Product Owners are passionate about the problem they are trying to solve. They want to get to the heart of it and do this best by engaging directly with customers and deeply knowing the data, insights and pain points about both customers and the business. Ideally the team would be attending the customer testing, but if they don’t then the Product Owner really has to be the voice for the customer, to put help the team to put themselves into the customer’s shoes and deeply understand their needs.

This is where Lean UX and Design Thinking intersect with Agile in order to build the right thing.

More Product Owners in Game of Thrones?

Do you have a good quote conversion from a Game of Thrones character to a Product Owner? If so post in the comments below.

What is a Minimal Viable Agilist?

I have been doing some hiring lately. The two roles I have been hiring for are a Scrum Master and a Business Analyst. I used the opportunity to test my recruitment questionaire – questions that I am expecting the organisation to ask in the future when I am no longer there in order to ensure that they are getting quality candidates into the roles.

The questions had some basic Agile bits, the sort to ensure that we were getting people who culturally understood T-shaping, the values and principles of Agile – not that they had to ring them off by rote, but they knew and understood what it felt like to experience them.

And then there were the role specific questions. For the Scrum Masters the test predominantly comprised a series of pictures with a question per picture. An example (without showing the picture) was “Take a moment to orient yourself to this wall – what issues do you see with the team/the work?”

If the Scrum Master applicant passed the basic Agile questions and the wall picture questions, stage three was getting them to demonstrate facilitating in a mock scenario.

Somewhat thankfully our search for a Scrum Master didn’t last too long – candidates that recruiters passed through to us all failed abismally. All of them didn’t even pass through the first stage to begin asking the picture based questions. Feeling despondent we did the whole ‘Who do we know who can do the job and are actively looking?’ thing. Interestingly they passed all three components of the test quickly.

So then the challenge was finding a Business Analyst, and that was indeed difficult. We had resumes without even a reference to the word ‘stories’, ‘Agile’ or ‘Scrum’ being put forward by recruiters despite being exceptionally clear that we were looking for Business Analysts who had strong experience in an Agile environment.

There were a couple that got through to stage two testing – but they were few and far between, many of our interviews got cut at 10 or 15 minutes.

It was very frustrating; we weren’t asking questions that were hard – we were asking questions that anyone who cares about being good at their job should be able to know the answers to.

So let me put this as simple as I can – if you aspire to be an Agile Business Analyst, or you think you are worthy of being an Agile Business Analyst and selling yourself as one, then these are the things I feel you should be able to answer (naturally these questions are more fluidic and are asked when a conversational element exposes their relevancy):

1. How do you decompose something down from a big idea to something that can be delivered by the team?
2. What qualities does a good user story have?
3. How do you know when a user story is small enough?
4. If you had a user story that was too big, what are the different strategies you would think of/use to try and break it down further?
5. What is the difference between Acceptance Criteria and Definition of Done?
6. On average how many Acceptance Criteria do you have per user story?

If the answers to the above questions are correct then the interview goes onto stage two – scenario testing. Similar to the Scrum Master test we provide a simple User Story and ask the person to define some Acceptance Criteria. Then we ask them to look at a number of poorly formed User Stories and tell us what is wrong with them.

Stage three, like the Scrum Master is practical, asks for a demonstration of analytical and breakdown skills through a scenario, ultimately to test facilitation skills and on the spot thinking.

Now I won’t reveal the answers to the questions above, but if you feel like giving a try and responding in the comments you are welcome to. Additionally I have left out some of the thinking processes that we have been looking for but I can reveal that answers like “I just do what I did back in waterfall – I talk to people and write the requirements. Business Analysis is no different in Agile than in a Waterfall environment,” is probably not going to get you the job.

But through all these interviews what I was most surprised with was how little people cared about the quality of their skills in their chosen profession. I am often frustrated and don’t know the answer as to why people know so little about their profession. Here are some possible root causes I have conceived of but I don’t know which is the right answer (I suspect it varies based on the person):

1. I am too busy doing my job to learn how to be more effective in it (too much work)
2. I work hard when at work, in my down time I don’t want to think about work or read about things related to my job, I just want to relax
3. I studied at school and for my degree, I was so glad when that was over I didn’t really want to study anymore
4. I am awesome and don’t need to know any more/get better
5. I am sick of people telling me what to do and how to do it, I am just going to do the smallest thing I have to in order to get my paycheck.
6. Understanding this change threatens my job in some way
7. I get by, no one else has commented on how I do my job

And so the ultimate question that it came down to in the interviews were “What is a Minimum Viable Agilist?” To me it is a person that cares about their craft, that understands the value of spending time to make themselves better and in doing so making the product better.

Source: Jeff Patton on User Story Mapping and Product Management

The product with the highest return on investment versus risk

Popularised by Eric Ries it subtly changes to

The smallest thing you can build that lets you quickly make it around the build/measure/learn loop

I must profess I have a few issues the MVP concept.

My first is the term. The term MVP is all well and good for you version 1.0 of your product, but what exactly is your next cycle through the loop called – is it called a Minimal Viable Product as well? Why do we not refer to the refinement or further iterations of the build, measure, learn (BML) loop as Minimal Viable Increments? Or better yet, BML increments? We know from using Lean Startup that we rarely get the product right first go, so we should have some simple term that talks about getting it closer to right shouldn’t we?

My second issue with MVP as a concept is that people forget that there is a life cycle to products if you do manage to be successful post the Startup phase. Let’s go through the scenario – you build your first MVP, you increment on it through build, measure learn, you begin to realise customer value, customer growth and manage to retain customers, you increase business revenue; in essence, your startup starts to succeed. Then your customers continue to grow. Suddenly your little tiny product is not handling the growth. You need to desperately take what was a tactical solution and industrialise it, strengthen it so that it can handle the next stage of growth. Your minimal tactical product just isn’t cutting it, it simply isn’t viable anymore. At this point in time the increments from a BML perspective need to focus on operational sustainability – how can you build a platform to sustain an acceptable performance? I call these minimal strengthening increments.

My third issue with MVP is that if you are doing it in a non startup environment – ie an intrapreneur in an already existing and flourishing business, is how to deal with reputational risk. In these large corporate organisations you need to worry about compliance to major standards, either in the country or internationally, you may also need to worry about how your existing shareholders feel about a non polished product out in the marketplace. It is for this reason that you could venture down the path of white-labeling the product, ie taking your brand off it and registering it under a smaller shell of the company, but often it means that the MVP becomes not so very minimal as the company is unwilling to incur reputational risk.

My fourth and final issue with MVP is the very difficult balance between MVP and minimal viable experience (MVE). Sure you could put a product out there to begin learning from, but if the content or the experience of the product is not compelling enough then you are going to risk turning away customers and that comes back to reputational risk for large corporations. Some call this a minimal lovable product.

Don’t get me wrong, I love Lean Startup, but in conclusion, if you are applying it into a corporate environment it is not going to be enough to ensure success and many different considerations need to me made. In a large and established organisation consider the minimal viable increment, the minimal viable experience, the minimal riskable product, and the minimal strengthening increments.