{"id":20716,"date":"2021-02-01T10:00:12","date_gmt":"2021-02-01T16:00:12","guid":{"rendered":"https:\/\/blog.planview.com\/what-evolutionary-biology-can-teach-us-about-moving-from-project-to-product\/"},"modified":"2021-02-01T10:00:12","modified_gmt":"2021-02-01T16:00:12","slug":"what-evolutionary-biology-can-teach-us-about-moving-from-project-to-product","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/what-evolutionary-biology-can-teach-us-about-moving-from-project-to-product\/","title":{"rendered":"What Evolutionary Biology Can Teach Us About Moving From Project to Product"},"content":{"rendered":"
\n
\"What<\/div>\n<\/figure>\n

Humans are biologically programmed to mistrust anything that deviates from the status quo. This trait has protected and propagated our existence for centuries. It’s why change is hard, even when backed up by solid reasoning and research, because it challenges norms that have been in place for decades. <\/span><\/p>\n

Take the COVID-19 crisis, for example. There is a lot of research to suggest washing hands is effective in preventing the spreading of the virus. Yet adding a more thorough and frequent two-minute hand cleaning routine to our daily routine hasn’t been as easy as it sounds. My own behavior changed after watching a compelling video that used a UV light to visually simulate the impact and length that washing hands had on parasites. That visual cue registered more quickly in my brain than other forms of communication. This response stems from evolutionary biology where visual cues are trusted more because they have saved us from predators for centuries. <\/span><\/p>\n

This behavior can teach us a lot about how we change our habits and culture, including how we transition from a project to a product-oriented mode for IT. <\/span><\/p>\n

Transitioning from a Project Model <\/b><\/h3>\n

Many enterprises in non-technological sectors, like manufacturing, logistics and banking, have worked in a project-oriented model for decades. Resistance to change is understandable as pivoting to a product model challenges long-held norms that have worked just fine. There is also understandable skepticism towards yet <\/span>another<\/span><\/i> “transformation.”<\/span><\/p>\n

Yet as evolutionary biology teaches us, just because something has functioned for decades doesn’t mean it will continue to do so. As digital disruption intensifies, IT’s focus on tracking activities, budgets and timeframes instead of supporting long-life product teams who focus on business outcomes will lead to extinction. <\/span><\/p>\n

Shine a Light on Your Digital Journey<\/b><\/h3>\n

Like the UV light video, we need a catalyst for change: a compelling and easy way to demonstrate the benefits of a product approach quickly to both teams and leadership in a way that doesn’t disrupt their daily lives.<\/span><\/p>\n

In my experience, quick adoption and a smooth transition to product hinges on three things:<\/span><\/p>\n

    \n
  1. Modeling your products<\/span><\/li>\n
  2. Measuring flow <\/span><\/li>\n
  3. Visually representing the impacts of improvements <\/span><\/li>\n<\/ol>\n

    1. Modeling Your Products <\/b><\/h3>\n

    It is vital that you start with a group of willing stakeholders along a specific product value stream (PVS) who acknowledge the need for a change. Then start small and do something impactful so the business will take notice. Once you have identified a value stream, the next is the most complex step of all: modeling the product.<\/span><\/p>\n

    The goal of modeling is to capture the end-to-end flow of value-creating and protecting work from ideation to operation. In a project organization, this flow is spread across teams, functions, tools, processes and even external parties like vendors. This complexity makes it hard to see the internal dependencies between teams and business units undermining flow.<\/span><\/p>\n

    The aim is not to get this right the first time, rather to start where you can and chart out what you know to iteratively expand and update. Carving out the relevant pieces for each product is an iterative process. It is critical that while modeling the products you do not make any changes to the way the teams work and keep disruption to a minimum. The more this process encroaches on the status quo, the more resistance you will encounter. <\/span><\/p>\n

    Product Modeling: Carve out all the pieces that constitute a product’s development across specific toolchains and organizational structure.<\/figcaption><\/figure>\n

    Aim to get to a point where you know where the work intake happens and how it flows through the various teams until value is delivered to the customer. A Value Stream Architecture (VSA) diagram can provide that visual cue:<\/span><\/p>\n

    A Value Stream Architecture exercise maps the flow of value-creating and -protecting software delivery work across your toolchain that underpins your product value stream.<\/figcaption><\/figure>\n

    Speak to us about a Value Stream Architecture exercise<\/a> and begin visualizing the flow of value today.<\/p>\n

    2. Measuring the Flow<\/b><\/h3>\n

    Once you have the product modeled, visualize the flow in relation to business outcomes. You want to measure flow in the current state against these outcomes to build a trend over time to reflect improvement. The simpler and more repeatable the visualizations, the better the adoption. So abstract the complexity to a meaningful level. Rather than a plane’s cockpit controls, aim for an iPhone-like minimalist approach. <\/span><\/p>\n

    Value stream management<\/span><\/a> (VSM) frameworks help provide this simple view. Using a set of value stream metrics, called <\/span>Flow Metrics<\/span><\/a>, you can measure the rate of delivery across your PVS against desired business results such as revenue, cost, quality and employee job happiness.<\/span><\/p>\n

    Metrics without this business context often do not provide the insights needed to help leadership make the right decisions to accelerate flow. If you don’t know why you’re doing the work and where you are, how do you know what to do and where to go? These metrics provide a common language that both technologists and their business counterparts need to understand about their current state to make more impactful decisions to progress. <\/span><\/p>\n

    Flow Metrics, from the Flow Framework®, define the spectrum of value creation in software delivery.<\/figcaption><\/figure>\n

    3. Visualizing the Impact of Improvements<\/b><\/h3>\n

    The dividing line between the tech oligopoly and everyone else is a rapid feedback loop from the market and end users for continuous improvement of products and services. <\/span><\/p>\n

    Whether it’s the software delivery teams doing the work, or the leadership funding and relying on results, we need to clearly demonstrate how small changes improve flow and validate its impact. For software delivery teams, faster flow empowers them and makes them more productive and happier. For leadership, they can gain confidence in the investments being made and quickly pivot funding to those that maximize business value; be it revenue, brand recognition or an active user base.<\/span><\/p>\n

    Some early findings from companies I’ve observed have included the following:<\/span><\/p>\n