3 shrewd project management lessons from lean product development - Yieldify | Customer Journey Tools

Search Yieldify

3 shrewd project management lessons from lean product development

Our Head of Business Change, Kim Goetzke, discusses 3 ways you can improve your project management processes by learning lessons from lean product development.

From tech startups to giants like Google, there is a lot of talk in product development about “running lean” and “building MVPs”.

However, many businesses, especially larger ones, demand extensive business cases for almost any change initiative and then apply traditional waterfall project management to manage and implement the change.

You could argue that there are reasonable advantages to this approach: It’s relatively easy to create and manage budgets as well as the progress of the change initiative itself. And, on an executive level, it is straightforward to understand where things are going because the problem and solution behind the change initiative are clearly described in the business case.

Unfortunately, many of us work in fast-paced, ever-changing environments where sticking to the well-defined business case often leads to committing to a solution that is out-dated by the time it’s implemented.

As well as time limitations, another major problem is obtaining management buy-in when:

  1. Complex/long projects offer few quick wins before completion.
  2. Cost projections are overwhelming against the background of high uncertainty.
  3. The risks associated with the initiative have not been addressed sufficiently and competitive pressures lead to discouraging risk-taking behaviour.

Due to the issues outlined above, many of the fastest growing and most successful software businesses eschew traditional project management and build products using lean methodologies. Because developing a new product is nothing more than a big change project, I believe that any change initiative, in any department, can learn from the field of product development.

Lesson 1: learn from your customers and focus on the problem, not the solution

– Key Take-Away –

Consider people affected by your change initiative as your “customers” and learn from them. Focus on understanding problems and pain points, not their suggested solution. This way you make sure to focus on the right issue

It doesn’t matter whether you’re working on an internal or client-facing initiative, you should talk to the people affected by the change – your “customers” – and learn from them.

However, don’t listen too much to what customers say they want.

It is your job to find out what really works – you need to learn how your customers behave and what they need. Focus on understanding their problems and pain points, not their suggested solution.

Based on your learnings from talking to your customers, you can come up with requirements for potential solutions. In order not to lose your focus, you should rank the requirements by priority for your customer and then draw a line to distinguish between must-haves and nice-to-haves.

  • Avoid focus groups and large group meetings as they facilitate groupthink, learn through informal conversations and 1:1s whenever possible.
  • The best feedback here usually comes in the form of qualitative data.

– Example – CRM implementation –

There is usually a trade-off between measuring everything management wants to know and minimising data entry for the end users. Helping your “customers” to find the right balance is your job but by keeping channels of communication open and by using them frequently, parties with conflicting interests will develop a better understanding of the other side and give you feedback to judge this balance more correctly. I would recommend (carefully) choosing “champions”, who are ideally well-respected, process-driven employees with expertise and a strong interest in the matter, in each team affected by the implementation.

 

Lesson 2: create experiments to test and refine potential solutions, iterate quickly

– Key takeaway –

If possible, break your initiative down into smaller components, each of which can be tested and implemented independently. This allows you to create value before project completion and to get feedback quicker. It makes it easier for people to adopt and, if necessary, allows you to stop an initiative before it gets too expensive.

Next, you have to build simple and cheap experiments to test how potential solutions resonate with your customers.

Try to break your initiative down into smaller components or stages, each of which is “shippable” i.e. can be implemented independently of each other. Validating your solution can be done through interviews, surveys, analytics or other means. However, be prepared to consider other options. If for example, your proposed solution doesn’t resonate with 10 out of 10 people, you may want to try a different solution.

– Example – CRM implementation –

Many implementation partners suggested by the CRM vendors will estimate the implementation to take more than three months. Because it is impossible to implement complex projects such as a (new) CRM without making post-implementation improvements, it often makes sense to isolate workflows (by team or value), rank them by priority and launch one after the other. This way initial value can be created within weeks instead of months and learnings from implementing the first stage can be taken into account for the second stage.

Lesson 3: pick actionable metrics that matter and focus on improving them

– Key takeaway –

Be precise about what you want to achieve i.e. your target conditions and use a limited set of actionable metrics that you track. This helps you to stay focused and communicate progress as well as results.

Many change initiatives, especially software implementation projects, try to solve such a wide range of problems that they fail to address even a single one effectively.

In their book “Lean Analytics”, Croll & Yoskowitz assume that at any given time there’s always one problem that we should care about solving above all else. While zooming in on a single problem isn’t always possible or feasible, the point is to understand that there is often a correlation between the number of issues you are trying to address and the quality of the solution, so keep it simple.

Once you’ve set yourself a clear focus, pick a few key metrics to monitor progress.

Not only does this force you to be explicit about what you want to achieve, it also helps you to communicate progress and results. The important thing here is that your metrics have to be comparable (e.g. a ratio) and actionable (i.e. change the way you behave) which requires having a rough understanding of the target condition(s) you want to achieve.

Depending on your project you can also use different key metrics for the different stages of the initiative. For example, a first set of metrics can focus on proving the effectiveness of the solution whereas a second set looks at scale once effectiveness is proven.

– Example – CRM implementation –

I believe that adoption metrics are vanity metrics at the beginning of an implementation project because a low adoption rate doesn’t tell you what to improve. Depending on how you break up the project and the problems to be solved, I believe it is often more valuable to use a combination of metrics around data integrity of the component you’re implementing and metrics assessing the value the solution is creating for the end user. At a later stage, the focus can shift to measuring productivity.

In conclusion

Whether you’re a decision maker in your business or trying to convince your boss to change the way your team can work for the better, you can learn a great deal from lean product development.

It can help you to minimise the risks of your initiative, reducing uncertainty regarding the solution, by creating initial value prior to project completion and by communicating progress as well as results through a limited set of actionable metrics.

If you’re interested to learn more about what Yieldify do, take a look at how we helped Domino’s achieve a 99:1 ROI with exit-intent overlays.

Appendix

  1. The term “lean” in the context of software development was first mentioned in Poppendieck / Poppendieck (2003): Lean Software Development: An Agile Toolkit. Lean software development as well as the lean startup philosophy, popularised by Eric Ries in 2008, are based on lean manufacturing, a production philosophy developed in the 1980s by Toyota.