Product Culture & Transformation – notes on “How to Create Tech Products Customers Love” – #11/11

Product Culture & Transformation - notes on "How to Create Tech Products Customers Love"

Product Culture & Transformation

Transformation Techniques

One transformation technique Marty recommends is the Discovery Sprint. He recommends to do a Discovery Sprint when a team struggles to learn how to do product discovery, when the team has something big and critically important to solve or if the team is just moving too slowly. Marty talks more about it on his blog https://svpg.com/discovery-sprints/ and refers to the Book “Sprint” by Jake Knapp et al.

Another is named Pilot Teams. The idea behind the Pilot Teams is to create success within a smaller protected environment and convince doubtful or fearful or lazy people to follow the change process. The principle is borrowed from the technology adoption curve (aka “Gartner Hype Cycle”) – some people are early adopters, others are less eager. Chris Jones from SVPG talks about this technique in “Pilot Teams“. With these pilot teams the idea of A/B testing – well known from product development – can be applied to organization development as well.

Outcome-based Roadmaps is yet another way to start the transformation process. Simply continue working with product roadmaps, however introduce two differences. First, annotate every roadmap item with its associated expected business result. Every time this item is discussed highlight the expected business result. Second, after the launch of an roadmap item report immediately the actual result vs. the expected result. So, during the next 3-12 month the opportunity assessment information will get its way into the roadmap. For prioritization try to move away from prioritizing ideas to problems.

Common Product Discovery Pitfalls

Marty mentions several pitfalls he experienced and saw teams struggle with. He talks a lot more in his blog post on “Product Discovery: Pitfalls and Anti-Patterns“. Here’s just a summary and some notes.

  • Confirmation-biased Discovery
    The team and / or the stakeholders are not really interested in the results of Discovery, they just need affirmation.
  • Product as Prototype Discovery
    The team pretends working on a prototype implementation but it takes too long to actually get the prototype shipped (e.g. 4 month).
  • Partial Team Discovery
    Not Technology, UX and Product go see the customer, it’s only Product + UX.
  • One-Dimensional Discovery
    The team focusses only on quantitative or qualitative validation and draws wrong or incomplete conclusions.
  • Big Bang Discovery
    The team works on a single, big release shipped within a lengthy time frame. They don’t work in an iterative mode.
  • Outsourced Discovery
    The organization / stakeholders hired a “creative” agency to do the creative Discovery work. The implementation should then be picked up by the team.

Culture Baseline of successful companies

“If we get the culture right, most of the other stuff will happen naturally on its own.”

Tony Hiseh, CEO Zappos
  1. Tackle Risks up Front
    • Value Risk – will they use / buy it?
    • Usability Risk – can they us it?
    • Feasibility Risk – can we build it?
    • Business Viability Risk – will our stakeholders support it?
  2. Define Products Collaboratively, not Sequentially
    • Product Management
    • Product Design
    • Engineering
  3. Focus on Business Results, not Output
    • Product teams exists to solve problems in ways that your customers love, yet work for your business.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

Where to start to speed up your IT environment – Here are 5 areas to look after.

Anil Cheriyan shared his thoughts on where to focus to create a fast and better working IT environment in the financial services industry – to speed up the organization (see: https://enterprisersproject.com/article/2017/6/suntrust-cios-formula-speed-relies-cloud-devops). In his post he mentioned 5 areas you should look after to break with old habits and start creating a fast pacing environment.

Anil Cheriyan is Director/Deputy Commissioner, Technology Transformation Services for the U.S. Federal Government. Previously, he was managing partner of Phase IV Ventures, a consulting and advisory firm.

Cloud

Two important aspects associated with the terminology “Cloud”. First it’s important to understand the implications of the various cloud strategies (ranging from private cloud over hybrid constructs towards public clouds). Get your strategy clear on which areas to host where. Criteria to look at are: business value provided, business continuity, resilience, security. Second aspect is the organization. Get your people involved. They need to participate in the strategy definition. They will execute them actually. No time for information hiding and bimodal IT infrastructures.

Modular architecture

Getting towards a modular architecture introduces flexibility in decisions, eliminates bottle necks and allows a decentralized governance. Today’s architectures are still monoliths or more advanced SOA stacks or somewhere in between. A more modular architecture exposes API’s via micro services. This architecture allows distributed ownership models. Complex is actually the implementation of these architecture rewrites. A lot of business related activities and the re-architecture work is a hard effort to combine.

DevOps

DevOps is finally all about the mindset of people and the break-up of silo-ed organizations. People need to learn and understand the importance of collaboration and trust. This sounds simple, turns out to be a heavy change project. Anil started pilot projects and introduced the true DevOps mindset and collaboration through success cases. It’s not about adopting rules and processes from the DevOps movement “by the books” – it’s about training your talent to work closer together.

Agile development

Agile development in software development is quite wide spread and commonly used. The acceptance over waterfall models is – where appropriate – high. Issues occur if the agile software development processes get surrounded by traditional waterfall-oriented functions – control functions. The most challenging part is to get agility into release management, deployment and integration testing.

Design thinking

Most important aspect of design thinking is the customer centricity. Understanding the real problems of the user to be solved is at the core of the approach. Not hunting the 100% perfect solution with all nice and “useful” features. Going for the most valuable solution, ship it fast. This requires heavy re-thinking within the organization. It’s more about talent and collaboration models. Important is to get people together with a thorough understanding of the industry and processes to help solving the customer’s pain points.

What is SCRUM?

What is SCRUM?

… or better said – what is it NOT?

When we introduced SCRUM we simply removed all project management structures and replaced them with agile – means SCRUM – process templates. We renamed “Project Manager” to “Scrum Master” and “Product Manager” to “Product Owner”. From this day on we were entirely agile. This worked fine for the – initial two sprints. User stories were small enough to fill up the sprint, they weren’t as complex to produce headache, and the overall spirit was positive and optimistic.

So, the bigger stories were produced by our product owners. One user story spawning multiple sprints? No problem at all. We started to work “agile” and followed the basic rules of waterfall (plan, build, run) forgetting all the nice agile ideals. Where we ended actually? Chaos and anarchism – no joke.

 

What lessons we learned – in a retrospective view?

  • SCRUM is a software development tool. It doesn’t free you from all the project management pain. Now, in our organization – we still have technical project managers looking after the huge topics or those needing external support. They get all the different departments organized and look after well-needed input from those departments – allowing the product owners to focus on their part of the game – filling the backlog and controling the product definition. We sorted out the mistake of renaming roles from the waterfal world into agile roles. Now, we have a thorough understanding of what the different roles in SCRUM mean – and what they have to focus on. And, more important where SCRUM roles end and you still need assisting roles.
  • SCRUM doesn’t replace your organization, roles and hierarchies at all – it allows a different view angle on these topics and highlight the product issues.

P.S.: If you were looking for a SCRUM introduction … Try these sources …