Lean product development processes are great for developing internal products and services such as those created by Information Technology departments for use within the organization. Lean approaches for internal products work well because the team continuously validates they are “building the right thing” that provides value to its customers and enhancing their value chain. Charting an efficient path to a useful product enables the natural demand from the internal customer base to support the product through its life rather than requiring ‘artificial’ support from executive sponsors (HiPPOs) to sustain itself.
From Lean Enterprise: How High Performance Organizations Innovate at Scale (Jez Humble, et al) we learn about the biggest risk to IT projects:
ROI in IT programs is not very sensitive to cost, but rather to whether the program will be cancelled and to the utilization of the resulting system. These variables depend primarily on whether we have built the right thing. However, the standard enterprise planning process provides almost no validation of this.
Most enterprise project and financial management processes validate only that project milestones and cost targets are being hit or missed. The lack of oversight of product fit by project and financial management processes makes a lot of sense since product fit is outside the domain of these teams’ core-competencies! See 3 Ways ‘Successful’ Projects Deliver Failed Products for differences between project and product success.
So…who is responsible for validating the product fits the customer’s needs? The product development team!
Of course the product development team might have a name like Web Portal, Human Resource Support, or Common Tools team, but they’re trying to create products and services that their customers create value with and need a good approach for doing so.
Sometimes there are no policies besides project and financial criteria for an internal product development to satisfy. In this case, a Lean product development processes can fill the vacuum and enable the team to build a product that internal customers love in an efficient manner or at least fail quickly with a documented list of explored hypotheses.
Often the product development policy requires the production of a “requirements document.” In the best case, these requirements documents are created collaboratively with the customers who will use it or their representatives. However, there is so much uncertainty surrounding most internal technical products that it is more-honest to label most statements about what the product needs to do as “hypotheses” than “requirements.”
Getting Started with Lean
Getting started with Lean product development processes is easy.
Lean product development has a simple Build-Measure-Learn loop at its core:
Lean Enterprise has good advice on how to get-going:
- Define the measurable business outcome to be achieved
- Build the smallest possible prototype capable of demonstrating measurable progress towards that outcome
- Demonstrate that the proposed solution actually provides value to the audience it is designed for
Let’s walk through this advice in-detail.
Define the measurable business outcome
This will often take the form of “Enable Role-X to Do-Y with Constraint-Z.” You may and probably should not be sure what the measurable business outcome of the product is in the early stages of the project. Use the first iterations of the process to work with your customers and see if you can define the measurable business outcome and assumptions of the solution together.
Example outcomes:
- Enable developers to have a functional development environment in less than 1 hour.
- Enable an engineer to build an application monitoring dashboard with less than 4 hours’ effort.
- Enable marketing team to conduct landing page experiments without per-experiment support from engineering team.
- Route new helpdesk issues to correct support team automatically with accuracy of at least 90%.
A survey of influencers within the customer community is a good place to start when defining the desired business outcome, generating hypotheses for what should go into the product, and risks.
The kind of analysis being done at the beginning of a Lean product development process and a classic requirements-driven project is roughly the same, though different in quantity. The Lean approach refocuses energy from comprehensive, and likely-inaccurate, documentation of product requirements to learning the product requirements from real customer feedback.
If the organization requires producing a requirements document before moving-on, then make a minimal one and ensure everyone understands the requirements document is just a starting point for the learning process.
Build the smallest possible prototype
Build the smallest possible prototype. The range of error in the solution space is greatest when first starting, so get as much feedback from real customers as possible to correct the product’s course before investing a lot of time in building things that no one will use. Real customer feedback is the best antidote to attachment to solutions that are attractive but do not actually provide value.
Methods for building the first version(s) of a product to gather feedback and tune vision:
- mockups
- paper prototype
- play-acting a ‘scene’ of product usage
- working prototypes – code will be ‘thrown away’, but learnings will not
- shell scripts with hard-coded data
- clickable / touchable frontend with mocked data
- concierge MVP – allow a real customer to use a prototype and implement the service yourself, manually
Use these early versions to discover and define the language of the problem space and the 1-3 key feature(s) the product must have in order to provide value to customers. If the product being built will replace an existing product, work through how the new product will accomplish the top 3-5 use cases of the old. However, be careful not to merely recreate the existing product; the new product should optimize the customer’s workflow so they can deliver more value, faster.
Demonstrate the solution provides value
Ask your single customer to use your product prototype and see if it provides value to them and if so, what. Measure the value in a way that quantifies progress towards the target business outcome.
Does the product provide the value? Is it the value you were planning for?
Learn from the feedback and decide if the hypotheses and assumptions being tested in this iteration have been validated. Find a way to measure the value provided to the customer-base at each iteration. It is advisable to implement some simple, automated means to measure usage and value being delivered early in the project, such as counting the number of requests to a particular page in a web server log.
The Secret of Lean
Demonstrating the proposed solution actually provides value to the audience it is designed-for is the most-often ignored step for internal products. In many organizations, people are forced to use inferior or inadequate products by mandate or lack of alternative. However, even if mandated usage is an option it is better to use Lean development practices for internal products because the Lean approach will:
- build a solution that provides the value customers actually need much faster (hopefully before money and patience runs out!)
- avoid investment in features that no one wants
- avoid the long-term costs associated with features no one wants
Adjusting product direction with an objective, quantitative feedback loop is the ‘secret’ weapon of Lean that eliminates unneeded work — use it!
Repeat & Get Traction!
Lean product development is an iterative process. Run the Build-Measure-Learn loop as quickly as possible in order to converge to a solid product vision and implementation based on real customer feedback.
Manage product risk by testing the riskiest hypotheses and assumptions first, embracing change.
Increase the number of customers exposed to the product regularly, ideally on each iteration through the cycle. Recruiting the first customers into a new product may take a bit of marketing and promotion. The Traction book is a great resource for learning how to new products can get traction with their potential customers. The good news is that internal customers are often easy to attract and please because they seldom have a product development team trying to serve their needs so directly.
If the product is really struggling to get traction with customers, then honestly re-evaluate the product’s vision, hypotheses, and assumptions. It is quite possible the product vision or available approaches are not viable and the product is going to fail — congratulations on determining this quickly with a deliberate exploration of the solution space!
Conclusion
Lean product development work well for internal products because the team continuously validates they are “building the right thing” that provides value to its customers and enhancing their value chain. The internal customer feedback enforces discipline on the product development process just as it would in a public market, yielding a valuable-producing product that stands on its own or a fast-failure and return of the project’s resources to the organization.
We’ll dig into Agile project management practices that can help keep product development projects on-track for success in later posts – contact us for immediate support.
