Category Archives: Agile Software Development

Product Discovery Techniques – notes on “How to Create Tech Products Customers Love” – #10/11

Posted on by
3
Product Discovery Techniques - notes on "How to Create Tech Products Customers Love"

Product Discovery Techniques

Don’t use these discovery techniques for bug fixes or optimization. They’re meant for real product discovery work, identifying and foremost validating big new product ideas.

1) FRAMING

Framing is the activity where the problem space is defined and the relevance of the problem at hand gets better understood. Do not spend too much time in framing.

See Marty’s blog for a more thorough description: https://svpg.com/assessing-product-opportunities/.

Opportunity Assessment

The Opportunity Assessment is enough 90% of the time.

  • What business objective are you focused on?
    typically one of the OKR objectives
  • How will you know if you have succeeded?
    typically one of the OKR key results
  • What problem are you solving for our customer?
    do you really know it’s a problem?
  • Who are you solving that problem for?
    typically a target market or persona from the strategy

Internal Press Release

The Internal Press Release is not intended to go public – it’s for internal use only. The anticipated audience is new product’s customers – actually it’s the team, management and stakeholders. It’s typically 1.5 pages maximum and written in “oprah-speak”, not “geek-speak”. Sometimes, 3-4 pages of FAQ for anticipated questions are added. The structure of the internal press release looks like this: heading, summary, problem, benefits, quote from you, customer quote, closing / call to action

Amazon uses Internal Press Releases for big ideas / efforts (e.g. site redesign or moving into new country).

An alternative to the Internal Press Release is the Happy Customer Letter describing the benefits for a customer written by the customer and the CEO-letter describing benefits for the company.

Marty writes on his blog about the internal Press Release and the Customer Letter on his blog: https://svpg.com/the-customer-letter/

Lean Canvas

The Lean Canvas is ideally used for a new business unit, a business line or a startup.

Lean Canvas by LeanStack (Creative Commons Attribution-Share Alike 3.0 Un-ported License)
Lean Canvas by LeanStack (Creative Commons Attribution-Share Alike 3.0 Un-ported License)

The canvas is described at great detail at LeanStack: https://leanstack.com/leancanvas

An alternative to the Lean Canvas is the Opportunity-Solution-Tree. It is introduced by Teresa Torres at her Mind The Product Talk 2017 in London “Critical Thinking For Product Teams“.

Marty talks about the different application areas of the Lean Canvas vs. the Opportunity Assessment on his blog: https://svpg.com/lean-canvas-vs-opportunity-assessment/.

2) PLANNING

User Story Mapping

User Story Mapping helps to visualize and deconstruct the problem or solution space. It provides an holistic view and gives context. Through the collaborative process it encourages shared understanding, identifies holes in thinking and improves planning and estimates. Furthermore it heavily influences prototypes and actually helps to scope releases for the product.

More information can be found in the book „User Story Mapping“ by Jeff Patton: https://www.amazon.de/User-Story-Mapping-Discover-Product/dp/1491904909 or here “Design Thinking in a nutshell – what is it and what’s in for us?“

A very good example on how workiva used User Story Mapping can be found here “Interaction Design for Enterprise Teams” by Jason Moore on Slideshare.

Customer Discovery Programs

The basic idea of the Customer Discovery Program is to discover and develop a set of reference customers in parallel with discovering and delivering the product. At the stage where the reference customer signs up for the program there is no product ready to be delivered. The Customer Discovery activity makes only sense for real big efforts, absolutely not for features. Serious enterprise customers are very likely to sign-up because they’re burned by the practices of Oracle, SAP and the likes – sell and run.

The reference customer bought the product without any side deals, runs the product in production and loves it enough to tell the world about it. In Customer Discovery, we’re looking for “Earlyvangelists”. An Earlyvangelist is best characterized by these criterion:

  • They have a problem.
  • They understand they have a problem.
  • They are actively searching for a solution.
  • They have a budget allocated.

See also the definition of the Earlyvangelist at https://steveblank.com/2010/03/04/perfection-by-subtraction-the-minimum-feature-set/.

With the Customer Discovery Program it’s simple to tell if product / market-fit is reached: achieved if 6 reference customer for a single market segment (e.g. industry, geography, …) are found. The product / market-fit product is the smallest possible product that meets the needs of this group. If you find only 4 customers or less this means the product market fit is invalidated and a pivot is needed. Work with 5-6 companies – and not more than 8. Talk to as many as possible – e.g. 50. Select only the most attractive for the Discovery Program, the other customers go into the beta program. Agree with the selected companies to be a discovery partner and ensure the right level of access to people and input. Agree with them to become a public reference if they like the delivered product.

In Enterprise business the goal is to find a single product solution that fits all discovery partners. Again, it’s important that all partners are from one single market segment. In Consumer services you should identify 8-20 Earlyvangelists and agree with them on regular phone calls to synchronize.

Examples for customer discovery: OpenTable (SMB), Symantec (Enterprise), Bazaarvoie (B2B2C), xoopit (Platform Services), Apple (internal tools), BarkBox (Consumer Service)

Marty’s blog on reference customers: https://svpg.com/the-power-of-reference-customers/

3. Ideation

Customer Interviews

Customer interviews are needed to understand your customer, to get rid of assumptions and start working with facts. Marty summarizes the value of interactions with customers in his post “Don’t talk to customers?“. Below are the key questions to answer:

  • Are your customers who you think they are?
  • Do they really have the problems you think?
  • How does the customer solve this problem now?
  • What would it take for them to switch?

Additional Ideation Techniques:

  • Concierge Test (see: https://pdmethods.com/concierge-testing/)
  • Public API’s (let others innovate on your product) – be aware of bad usage: Cambridge Analytica + Facebook
  • Hack Days (directed and undirected)
  • Data Spelunking (Hackathon on data)

4. Prototyping

The prototype should minimize the time by factor 10 to provide something to look at. See more on prototypes at Marty’s blog “Flavors of Prototypes“.

User Prototypes

User prototypes are created very fast and lightweight by nature. The prototypes are used for value testing with a consumer or customer to quickly gather feedback on both, usability and value. Low fidelity user prototypes are used for team internal iterations. Use high fidelity prototypes to show-case internally to executive people. The prototype is usually created by the Product Designer with support from the Product Manager. Ideally, when finished, the prototype could be used as a specification for the Delivery process – “prototype-as-spec”.

Paper prototypes are too limited by nature, use wireframing tools (e.g. balsamiq, axureRP, proto.io, FLINTO, UXPin, marvel, invision, Adobe XD) instead. They allow interactions with the prototype and are no more effort to build.

Feasibility Prototypes

The feasibility prototype validates the solution approach. Usually, the prototype is build by engineering to gain further insights on the implementation and test technical (e.g. scalability, performance) risks. The prototype might not be more than a code fragment or a successful validation of a 3rd party software or API integration. It may also happen that product people are not involved in the prototype at all.

Live Data Prototypes

The purpose of the live data prototype is to collect further evidence pro or contra a product decision. This prototype is more expensive to build than the user prototype, but still far less than the actual product. The prototype is not the real product, it’s usually 5-10% of the real product. It includes quantitative a/b-testing but also qualitative testing and is based on real data. A small amount of real traffic could land on the prototype to collect data. Engineering is typically needed to create the live data prototype within 2 days up to 2 weeks.

A lot of people get excited when they see the live data prototype and tend to confuse the prototype with the real product. But there’s still a significant difference between production ready software and the live data prototype. The real product needs:

  • All required use cases
  • Instrumentation / analytics
  • Test automation
  • Scale and performance
  • SEO work
  • Maintainability
  • Internationalization / localization

A good example of a live data prototype is Amazon’s “Frequently bought together” feature. The idea of building the features was rejected by SVP Marketing. So, strong evidence was needed because it was simply too expensive and risky to productize the feature without further evidence. So, the team decided to build a live data prototype with a small amount of real traffic in a specific product category. The prototype was a/b-tested and the collected data provided a significant uplift in business KPI’s. This is a great example of a high-integrity business case.

Hybrid Prototypes

Hybrid prototypes mix those elements needed to tackle the specific risks at hand. They blend various techniques and are mainly limited by your own creativity.

A good example of an hybrid prototype is Zappos. Zappos solved the problem of female shoppers to buy fashion shoes online. They defined and understood their personas and their key problems with shopping online: 1) returning goods 2) no timely delivery 3) not knowing the size 4) bad product images. Zappos prototyped a potential solution to the persona’s problems by mixing a variety of prototypes: user prototype (appealing front-end), live data prototype (product catalogue and images) and the “Wizard of Oz” (buying the shoes at the shop over the street and delivering to customer). Most important was: the users shouldn’t recognize the prototype character of the solution. Zappos controlled the amount of traffic via AdWords and made sure they could handle the manual part. So, with this mixture of prototypes – that for sure doesn’t scale – they could validate demand, value and usability.

Testing Product Ideas

“Prototype as if you know you’re right, but test as if you know you’re wrong.”

d.school

Marty writes in his blog about “Prototype Testing” more detailed on the various ways to testing.

5. Testing Usability

Usability testing includes interacting with customers, getting their feedback. For the test session, have the prototype ready – up and running and focus on the prepared questions to understand if users have issues using your product. The session may be conducted at your office, the customer’s office or at a mutual convenient location (e.g. Starbucks) or – if not possible – remote via video conference.

Recruiting users in B2B context is done via the customer discovery program, in B2C via AdWords. AdWords allow acquisition of users based on keywords and / or geo-targeting. It’s the most cost-effective solution and easy to stop and restart again. Payment is entirely based on performance.

6. Testing Value

Testing value focuses on three aspects: testing demand (is this really a problem?), testing efficacy (how well does the product solve the problem?) and testing response (how excited are the testers?).

Testing Demand

Testing demand answers the question if people are willing to use the product, if they understand the value and see the product solving a real problem they have. Marty talks more about Desirability Testing on his blog about “Product Validation“. Some techniques for demand testing are described below

Fake Door Test

A fake door test fakes a product feature for the customer. If the customer acts with the fake product a thank-you-message is displayed and sometimes contact information is collected. Furthermore, nothing happens. The goal of the test is to collect data, to measure the click-thru ratio. More information on the fake door test can be found here: http://learningloop.io/plays/fake-door-testing.

Landing Page Test

A landing page test pitches product features, products, product lines or other promises to the customer combined with an explicit call to action. Push traffic on the landing page via e.g. AdWords or other comparable methods. Now, measure the conversion – how many people do actually interact with the landing page and are interested enough to follow the call to action? With the click, nothing happens with the customer other than a friendly thank you message and sometimes the question for contact details. More information on the landing page test can be found here: http://learningloop.io/plays/spoof-landing-pages

Explainer Video

The explainer video shows a high fidelity prototype at work. It’s basically a video of a product demo. It is then distributed and measured like the landing page test above. The goal, again, is to measure demand for the demoed product. More on the explainer video: http://learningloop.io/plays/video-demo

Kickstarter Testing

A great way to test a product idea without jeopardizing your brand is to test demand on kickstarter.com. Just place the product idea at the crowdfunding platform as a “nobody”. If the idea creates enough buzz it’s worthwhile a further investment, if not it can be dropped silently without creating any noise. Read more on the idea from Mark Dwight “How to Kickstart Your Market – Why even established companies can use crowdfunding.“

Qualitative Value Testing

“Find everything that’s wrong with the product and fix it; Seek negative feedback.”

Elon Musk

Qualitative testing explains why it’s working or not, it gives insight why something is happening or isn’t. It doesn’t try to prove anything. You won’t get the answer from any one user test; every single test provides another piece of the puzzle. It’s important to test with real users and customers to judge the value.

Qualitative value testing is done with prototypes or the real product. It provides insights from usability and value perspective. On top it usually provides unexpected insights from the customer. It’s typically done fast and cheap. To really understand how much customers value the product, various questions or tests can be conducted:

  • Payment – will they pay for it?
    credit card information, pre-order form, letter of intent (in B2B)
  • Reputation – will they recommend it?
    NPS, introduction to peers or the boss, public reference
  • Time – will they meet again? Will they invest their time?
    agreement on follow-up meeting, non-trivial trial
  • Behavior – will they switch from their current solution?

Quantitative Value Testing

“Features are not inherently valuable. The value for our customers is only realized when a feature fulfills a need. It’s only realized for our business when we see the results of our work move the needle. That’s why we need to concentrate on the outcomes over the outputs.”

Melissa Perri (see: https://melissaperri.com/)

Quantitative value testing can provide evidence or even proof that something truly works – or isn’t. It generally can not explain why it’s so. It’s done to get a clearer picture on the impact on your revenue, your brand, your customers and also your employees.

Quantitative testing can be done with the existing product – or a live-data prototype – in an A/B testing setup on a certain amount of your traffic. Alternatively, it could be done with a limited amount of your customer through invitation. In a B2B scenario, you’d use your existing customer relation via the Customer Discovery Program to get exposure of the test to people.

A good example for a quantitative value test is Spotify’s “Discover Weekly” feature. Data collected in an A/B test was compelling enough to fully implement the feature. The launch-ready implementation included some big hurdles and a lot of effort on the data crunching side. So, it was well worth the effort to test – before – putting the feature in Delivery.

7. Testing Feasibility

Testing feasibility mainly addresses technical concerns – are we able to build this at all? To test feasibility it’s important to create prototypes that focus on the key areas of concern. Emphasize speed of learning over reuse of the written code. Your Tech people need to answer these questions:

  • Do we know how to build this?
  • Do we have the skills on the team?
  • Do we have enough time?
  • Do we have the right architecture or components?
  • Do we understand the dependencies?
  • Will the performance and scale meet our needs?
  • Do we have the infrastructure to test and run this?

8. Testing Business Viability

Business viability – does this feature / product fit with our business? – needs to be addressed to be successful within the own organization. Your stakeholders (e.g. Senior Executives, Sales, Marketing, Finance, Legal, Security, Business Operations, …) need to be informed regularly, you need to earn their trust. Have discussions with them and make them feel you understand them – but remember: everyone has a voice, but not a vote! Try to engage individually with them, group meetings can cause a lot of damage and are harder to handle. When talking to your stakeholder, have your data ready – data always beats opinions. And read the signs during the meeting – differentiate between stop signs and yield signs.

Techniques you can use for a stakeholder meeting is typically a high fidelity user prototype and / or a product walkthrough.

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.

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

Posted on by
3
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.

When to use waterfall, when agile?

Posted on by
9

Software projects failed a lot in the past. They failed to deliver the value for the business, were too late or ways out of budget. The selected process method was usually the scapegoat for the failure with agile methods being the answer to any question in software development. But as usually in live, it’s not black or white. The selection of the right software process method depends on the surrounding of the project. I gathered some industry input and combined it to reflect the current thinking regarding agile software development methods vs. traditional methods.

The adapted Stacey matrix

Adapted Stacey Matrix for technology / software development environment

The original stacey matrix supports decision making processes suggesting appropriate management actions and defines four areas: simple, complicated, complex and chaotic. The suggested actions depend heavily on the context of the decision making.

The dimensions of the adapted matrix: HOW and WHAT

The x-axis of the adapted matrix deals with the HOW. If the team knows the technology well and has used it many times before, we’re on the left. Otherwise, if the technology is completely new to the team we’re on the right of the dimension. The y-axis positions the WHAT. On the bottom of the axis, the stakeholder of the project all agree on the goals and have the same understanding of the expected outcome. On top it’s the opposite, no agreed requirements and no alignment on expectations. The individual mix of the project points to a certain area with a process model suggestion in the adapted matrix.

Waterfall …

Waterfall is a traditional project management method with sequential steps and no iterations. Massive upfront planning is done before any implementation work starts. If all goals and steps are clear, waterfall produces consistent results in a predictable and repeatable way. The clearly defined tasks lead to an optimized sequencing and optimal resource allocation. Waterfall optimizes resources and return on invest if cause and effects are clear to anybody in the project team.

… vs. Agile

Agile stands for SCRUM, Kanban and LEAN methods with flexibility, quick response and constantly changing environments in mind. They start quicker with smaller scope for the current increment with the scope being like a rolling window. Uncertainty of the projects’ goals needs quick adjustment and adaptation during the whole execution. Only close and frequent collaboration with all team members make agile projects successful. If causes and effects aren’t clear, agile works in small steps towards a value-generating and broadly accepted result.

Simple to chaotic – from “known knowns” to “unknowables”

Simple = easily knowable, the known knowns

Projects in the simple zone unveil very few surprises, decisions are fact- or evidence-based, advancement occurs in orderly, sequential steps and the WHAT is clear to anybody. Any size projects with clear activities and repeatable results fits in this category. It has been done multiple times before and best practices exist as benchmarks. The process is simple and could be handled in a check-list style.

Going forward in a simple, fully predictable project means reducing it to the maximum to make the single pieces easier to understand. Examples of simple: recipes, tasks on an assembly line, checklist based work.

Complicated = not simple but still knowable, the known unknowns

The complicated zone segments into socially and politically complicated and technically complicated. Complicated means less simple but still somewhat predictable.

In Social/political complicated environments people can not agree on the purpose of the project and the expectation on results is not clear. Requirements are conflicting amongst the diverse stakeholder which could be resolved with waterfall to get clearance on WHY before WHAT before HOW. On the other hand applying agile techniques could help convincing stakeholders to agree on already achieved results and smoothing the further requirements discussion. The project team needs to pay special attention on getting early agreement between stakeholders in place.

In technically complicated contexts it’s clear on WHY and WHAT to achieve. Still, the HOW is not clear. An agile iterative approach helps getting feedback from the project team on the achievements making adaptations possible.

Going forward in a complicated project means as well reducing it to the maximum to make the single pieces easier to understand. Technically complicated is e.g. using a specific technology for the first time. Political/social complicated is e.g. if the relation between cause and effect are not clear enough or conflicting opinions amongst various stakeholder exist.

Complex = not fully knowable but reasonably predictable, the unknown unknowns

The complexity zone stands for high risk and uncertainty and requires a high feedback frequency. Neither requirements nor the execution are clear. Holistic defined process methods don’t work any longer. The context asks for a more explorative approach with transparency, frequent inspection and adaptation. SCRUM as a process method in the toolbox of the agile mindset is the method of choice. It increases transparency with small iterations and frequent check-points allowing cheap adaptations. The team planning is the start point for each new iteration and allows immediate feedback from stakeholders to the teams to adapt the next iteration.

Complexity can not be reduced, some understanding can be achieved and complexity can not be planned, it simply grows. A good example of a complex project is software development in general. The requirements are rarely fully defined right at the beginning and it’s seldom clear which architectural solutions are superior to others.

Chaotic = neither knowable nor predictable, the unknowables

In chaotic zone requirements and execution path are both undefined and the risk is high. Kanban as the most flexible project management method is the tool of choice. With no structure like sprints and the only focus on work in progress (WIP) Kanban focuses on continuous delivering results to allow further modifications in direction and backlog items.

The goal is to move from chaotic towards complex by dividing the problems. The principle “Act, Sense and Respond” helps navigate towards the zone of complexity.

Sources – from where I learned:

Design Thinking in a nutshell – what is it and what’s in for us?

Posted on by
1

What is Design Thinking?

Design Thinking puts one person group in focus – the user. All activities in Design Thinking circulate around making the user’s life better. Design Thinking is an activity where all stakeholder take part. Not only designers, product owners or developer are part of the group, marketing, community management, finance and even legal should be involved in this very early stage of the product development cycle. Why should they? It’s a matter of understanding and communication. All participants of the Design Thinking process are part of goal setting, reasoning and the detailed planning. They need to share the vision behind the product. Time is wisely spend in the beginning to smooth the following implementation steps. Involvement of participants? 100%. No e-mails, no meetings, just the user and their pain points.

Other names for Design Thinking are “Design Sprint” (Google) or “Iteration 0” (infoq) or “Design DOING”. Design Thinking is a great planning tool to let all people understand what is build when and with what purpose. The process consists of a set of methods typically executed directly before the typical lean and agile development cycles start. It defines what to build and to communicate this purpose amongst the participants in an efficient, effective and fun way.

What’s the result of Design Thinking?

The result of the Design Thinking activity is a verified prototype, common understanding of what to achieve and a plan on how to proceed building the Minimal Viable Product and which features to add after going live. On top of that comes the certainty to build a set of functions that user’s really want and need – not a feature an executive has fallen in love with. Further definition of Design Thinking: IDEO, interaction design foundation or wikipedia.

What’s the purpose of Design Thinking?

  • Customer centricity uncover real user needs
  • Boost communication and understanding bring business and technology together – let the whole team understand what to build and for what
  • Create business value create and test solutions for these user needs
  • Be better and faster build better products and bring them to market sooner
  • Be focused and measurable extract clear goals from real customer needs
  • Get prioritization right feature prioritization gets a lot easier (no “pet” features)

Phases of Design Thinking

Design Thinking is a fun exercise, fast paced with the goal to create a concrete problem definition and an implementation plan for the most promising solution.

5 Phases of Design Thinking

Starting with an idea of a user problem in mind the user observation phase results in a better understanding of the real user pain points. The team identifies the root pain points of the users and document them in an experience map. Creation of multiple solution ideas means to apply ideation techniques with the clear goal in mind of not implementing the first-thought-about solution. The paper prototype challenges the solution idea from ideation with the lowest possible effort and tries to resolve the user’s pain points. The implementation planning starts right after the finalization of the paper prototype. The result of the Design Thinking process is an implementation plan.

Implementation Guideline – Design Thinking in 10 Steps

1 – Identify user pain points

Go out of the building, watch, observe and interview real users experiencing the problems to solve by the solution you’re about to build. Watch at least 8 individuals! User’s verbal feedback usually contains their thinking of solutions, not their problems. The understanding of the team prior to the user observation is significantly different from it after watching and talking to users.

2 – Show the customer journey on an experience map

The experience map shows the current product experience (if any) and the user pain points. Organize notes from the team’s observation phase on sticky notes on a wall. All members of the Design Thinking team take part in the observation phase and make their own notes. The experience map shows the flow from the beginning (left) to the end (right) of the user journey.

Experience Map

From top to bottom the experience map shows the separate steps (above in blue) in the user journey. Below the user journey steps yellow notes represent the observations from the team members. Themes / cluster – represented in green – create an umbrella for the various observations. Additionally, emotional states – e.g. with smileys – enrich the overall journey and make it more visual.

3 – Extract and prioritize pain points

At this stage the experience map contains contains a lot of observations from various people. The next step in the process is to extract the pain points to focus on during the remainder of the process. “Dot-voting” is the tool of choice here. Each participants gets 4 to 5 dots. The biggest pain points receive the dots. Dot-voting happens all at once – at the same time. Observations may receive none, one or many dots from each participant. Counting the dots identifies the most important pain points.

4 – Goal and metrics setting

Having the ordered list of pain points extracted, the next step is to convert them into goals and make the progress measurable. Setting the goals can result in either quantitative or qualitative metrics. If possible assign real numbers to the goals. Orientation criteria for setting the goals can be:

  • efficiency (e.g. time spent on task)
  • effectiveness (e.g. reduction of # of errors)
  • satisfaction (customers’ happiness with the solution)

5 – Create example people – personas

Instead of developing a product for anybody – and hence most likely nobody – define real people, personas. Be specific and narrow user segments down. The persona should include the name, attributes, goals, concerns, quotes and other emotional elements. Ideally extract only 2 to 3 personas either individually or in small groups. Share the results afterwards with the rest of the group.

6 – Ideation – create ideas to solve pain points

Now it’s time to think about multiple solutions to address the user’s paint points. Don’t jump to solutions – don’t build the first “obvious” solution. Most likely there are more clever approaches available. All participants take part in the solution creation phase. Individuals create ideas time-boxed (e.g. 15 minutes). Afterwards they share them with the broader audience. There are no stupid ideas – it’s important to listen carefully to all ideas – some of them will stipulate further thinking. After the individual session a group session to detail the most promising ideas follows. Involving all team members creates shared ownership for the solution.

7 – Reality check

During ideation the goal is to create a lot of ideas. Are they all feasible? Can they really solve the issue? How does this look in reality? Since the ideas are in early stages we need to check them with reality. Place the ideas on storyboards. The storyboards show the interactions of the users with the idea. They are a sequence of scribbles which fit easily on a sheet of paper and focus on the positive user path. Let all edge cases, negative paths, recovery steps aside. Just focus on the positive user experience path associated with the idea. Reality check happens as an individual task or in smaller groups.

8 – UI Paper Prototype

The reality check sketches the user flow on a very high level – only focusing on the positive path and keeping intermediate screens aside. With the Paper Prototype the user flow should be as realistic as possible. Now the team members need to think through intermediate screens and pop-ups, edge interactions with the user and error cases as well. They transform the high-level storyboard an user interface. Sticky notes represent the UI elements – so the elements can change easily.

9 – Usability testing

Now it’s time to get real feedback from real users on the ideas developed. Any feedback is welcome and influences the prototype iterations. Feedback is usually more open since the prototype signals “Hey, we’re still in early phases. Don’t hesitate to give honest feedback!”. For the overall product changes at this stage are ways cheaper than rework done in later phases. Identify around 5 test participants – ideally based on the persona descriptions used so far in the design process. The storyboard serves as the base for tasks for the participants. The UI needs to change as an answer to the actions of the participants. Do so by exchanging notes or other elements of the UI manually. During the Paper Prototype testing give the participants no hints. The overarching goal is to identify gaps or errors in the user flow and collect feedback to improve the prototype.

10 – Implementation planning

The last step to finish the Design Thinking process is to come up with an agreed-upon implementation and launch plan. The plan is incremental in nature, delivers business value as early as possible and involves all disciplines. Implementation planning usually results in a story map which reflects the desired state of future interactions. Jeff Patton explains story maps in great detail in his book “User Story Mapping”. Here are only some important aspects.

Story Map

What’s the story map?

The story map is a one page explanation of the big picture and shows details of the planned product or feature. It includes a release strategy, describes iterations around the minimum viable solution and identifies areas for additional research. First of all list all stages of the user journey as they use the product. This is usually similar or equal to the blue sticky notes produced in the experience map. Below, in green, put the concepts of the UI which help to fulfill the step in the user journey. Yellow notes hold capabilities of the product extracted from the paper prototype. Take a note on the sticky notes of the expected outcome the capability delivers to the user. The yellow notes usually translate into implementation epics in agile development. Put pink notes on capabilities marking additional research need.

With the finished story map, you have a quite comprehensive view of what needs to be build for a perfect solution. To further mitigate risk of failure you want to start with the least minimum effort in development – identify the minimum viable product feature set. Now, it’s time to sort the yellow sticky notes below the UI areas according to their criticality to the product success. Sort them into these categories having the question in mind: “How necessary for users is this capability to fulfill their task?”:

  • critical: absolutely necessary for user to get tasks completed
  • commercially acceptable: adding these features will allow commercial success
  • later: add capability later
  • nice-to-have: capability which can be added in later phases if time allows
Story Map with prioritized capabilities

When finished with the prioritization, you have your iteration planning finished. The top lane includes all capabilities needed for the minimal viable product. Next lane adds functions to enable commercial success. Later lanes store further functions to add to the product to become a full solution.

Find some videos on lynda.com by Chris Nodder on the specifics of each step and the applied technique (need a Lynda.com subscription).

Design Thinking – Timeline

Typically Design Thinking activities fit into a 5 days week. You might want to organize them like this:

Design Thinking – week template

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

Posted on by
Reply

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.

Architecture alternatives for rendering a web site

Posted on by
Reply

There’s a great overview of technologies available from Google comparing the different architecture options to render a web site. Jason Miller and Addy Osmani present options from SSR (server-side rendering) over various mixed models to complete CSR (client-side rendering). They describe the pros and cons of the various approaches and give hints on what to use in which situation. A great read!

https://developers.google.com/web/updates/2019/02/rendering-on-the-web

Rendering options

  • SSR: Server-Side Rendering – production of HTML is done on the server
  • CSR: Client-Side Rendering – creation of HTML is done on the client, usually using the DOM
  • Rehydration: Using a JavaScript based client app to show the server-rendered HTML – mixed with the DOM tree and associated data
  • Prerendering: generation of HTML is done during build time

Performance acronyms

  • TTFB: Time to First Byte – time between clicking a link and the first bit of content
  • FP: First Paint – time until any pixel gets visible to the user
  • FCP: First Contentful Paint – time until the requested content (article, body, ..) becomes visible
  • TTI: Time To Interactive – time until a page becomes interactive

Jason and Addy wrap their great article up with an overview of the options. Since it’s presented under Creative Commons Attriubtion 3.0 License I decided to reproduce it here for further reference.

Toolbox, Best Practice, Tools, HowTo’s – agile practices and how to apply them

Posted on by
Reply

The internet holds quite a lot of information. Here’s my favorite collection of tools, toolboxes, methods, best practices and howto’s from various fields of application. Most of them have a tight coupling to agile software development, agile organization development, product development and cross those fields.

Following a list of links and a short description of what to find on the site.

Open Practice Library, https://openpracticelibrary.com/

The site contains methods and tools around product Discovery and Delivery practices. The methods are collected by the community and serve to inspire seeking minds to test them in various situations. The methods are positioned in 4 main areas: Discovery, Delivery, Options Pivot and the Foundation.

Discovery contains methods like:

Options Pivot holds tools like:

Delivery contains these tools:

Foundation hold something like these:

Ideo – Design Kit, http://www.designkit.org/methods

This is a collection of tools around Inspiration, Ideation and Implementation. The kit is provided by IDEO.org.

Inspiration

Ideation

Implementation

Other Tool Sets

Realistic case study on agile development at large scale

Posted on by
Reply

“A Practical Approach to Large-Scale Agile Development” by Gary Gruver, Mike Young and Pat Fulghum is a real-world example on how scaling of agile software development really works in a huge software producing organisation.

A Practical Approach to Large-Scale Agile Development

The authors describe in an easy-to-read language the journey of the HP firmware organisation starting in 2008 and taking around 3 years with a clear goal in mind: “10x developer productivity improvement”.

In the beginning they were stuck with a waterfall planning process with a huge planning organisation and not being able to move in software development as fast as business expected. A quick summary of activities showed that in the beginning the organization was spending 25% of developer time in planning sessions to plan the next years’ releases. Only 5% was spent on innovation. Nowadays, after acomplishing the 10x goal, 40% of developer’s time is spent on innovation.

The book highlights the relevance of a right mix of agile technologies with a good approach in software architecture and organisational measures to form a successful team of people striving for common goals. A fascinating read!

Most striving is the unemotional view on agile and how to apply it. They purposefully decided not to have self-organizing teams. So, agile is broken? Can’t be applied in such an environment? Not at all! The authors give good reason for not applying all agile patterns from the books – and it is working.

Agile at LEGO

Quote

Posted on by
1

I am interested in agile software development methods, LEAN management styles and the impact on a company’s organization. All these attributes are usually associated with software development companies – not hardware companies or toy companies.

I got a “must-read” recommendation for the book “brick by brick” by David Robertson. "Brick by Brick" by David RobertsonThe book proved to be a real “must-read”. Especially the portion where David Robertson describes the turnaround of the company. The methods applied to an almost bancrupt company reminded me to techniques nowadays well-known in software development teams. I mailed David Robertson and asked for permission to cite a portion of his book (page 170, Brick by Brick, David Robertson):

Before the rise of Bionicle, the LEGO Group’s product teams were soloed from one another and toys were for the most part developed sequentially: designers mocked up the models and then threw their creations over a metaphorical wall to the engineers, who prepared the prototypes for manufacture and then kicked them over to the marketers, and so on down the line. Rarely would one team venture onto another team’s turf to offer a suggestion or ask for feedback. If all went well, the team’s product would hit the market in two or three years.

The Bionicle team’s six-month deadlines forced a different way of working, one that was less sequential than parallel, and highly collaborative. Once the outline for the next chapter of the Bionicle saga was roughed out, the different functional groups would work side by side in real time, swapping ideas, critiquing models, and always pushing to simultaneously nail the deadline and build a better Bionicle.

“We had a massive project team,” recalled Farshtey. “It wasn’t just the creative people; it was also people from Advance and from marketing, sales, events, PR – all different parts of the company, all helping to steer the franchise.”

Because the marketing group worked directly with designers, Bionicle’s advertising campaign felt connected to the product. Promotional posters for Bionicle’s first-year run had to look and feel of movie posters, precisely because the toy featured the powerful visuals and narrative sweep of an epic film. “We wanted more communication in the product and more product in the communication,” said Faber. “That meant the marketing group needed to be involved at the very start of product development, so the story flowed out through the product. We wanted the product almost to tell the story by itself.”

“We had a kind of triangle, where the marketing, the story, and the product had to move ahead together,” he continued. “None of those could be the spearhead. Each needed to support and inspire the other.”

That single page really got to a point. I’m relentlessly telling that the core of the agile movement is about focus and collaboration (see Agile Defined). Usually, I refer to these values in software development environments, organizations and teams. But LEGO – a brick & mortar company – used the same principles in 2001 to turnaround their company. That was really mind-boggling news to me.

After doing some research on this topic, I found a SMB here in Germany working with agile principles: HEMA Bandsägetechnik. This (german) article talks about their experience.

 

Customer & Service Provider interface – the End of the Story

Posted on by
Reply

Customer & Service Provider interface … the End of the Story 

With the start of the-then-new job in October 2015 I started writing about my experience – and especially the shortfalls – in our customer and service provider relationship. It turned out to become a triptych. This is the final – the wrap-up.

To catch up you might want to read the first post: “Customer & Service Provider – Epic fails” and the second in this series: “Customer & Service Provider – silver lining on the horizon“.

You might ask yourself … why is that the end of the story? Improvements in processes usually don’t have an end. Well, let’s see.

The Modified Setting

In the meantime we upgraded from 2,5 software developer to even 3,5 software developers. Ambition behind is …

You might guess it? …

Come on …

YES! Right – on the first attempt.

Speed up the delivery of features. Our senior management is delighted by the achievements so far – however is far from being satisfied with the results, the outcome. Still, there is great belief that more people build more results. True! BUT we’re still having the issue of not well-defined requirements and still having long periods of wait for answers from our business leads.

On a daily basis we’re still in communication mode. Twice a week our project manager and the project manager of the service provider meet to exchange progress and start discussion on new topics. Again, communication proves to be a gold nugget!

The Now Situation

Missing product management – It became so obvious, so non-neglectable, so crystal-clear. Reason behind the low througput of our development cycle is not the lack of software developers – that’s a symptomatic solution. No, root cause is: we’re lacking a professional approach to manage our products – product management is missing. Usually, product management’s major duty is to define requirements on their products and harmonize the various needs and demands from all involved parties – customer, departments, management.

If we just had some people doing exactly this job. World would be much clearer!

  • Prioritization would be easier – since the product management would clearly include management in the overall prioritization process.
  • Definition of requirements would be clearer – only well-defined stories were handed over to our service provider.
  • Decision points would be clearer – product management is the definition point for detailed questions and processes.
  • Communication would be simpler – it’s simply clear whom to ask for guidance.
  • Development would be faster – no impediments any more … why should it be slow now?

In my last post, I raised a lot of points:

  • Multiple stakeholders talking to the service provider
  • No clear communication of priorities, requirements and goals
  • Fundamental changes in design after going live
  • Bad requirement quality
  • Silo thinking
  • Low quality – not well thought-out
  • No consistent prioritization

All of them – I really believe – all of them could be solved with the implementation of an organizational change – introduce product management.

So, you might ask yourself why is this the end of the story? Well, that’s an easy one. Despite my continued effort to convince my senior management about the absolute need to improve the organization by introducing a product management person (yes, one person!), I failed. “Too expensive”. I personally decided to quit.

Lesson learned?

I’m still convinced we changed a lot for the good in the customer / service provider interface. Agile patterns did a great difference for all of us. Furthermore, the service provider did invest in agile coaching (and architecture consultancy as well … not all is gold …) and showed great willingness to cooperate – to improve.

Go on, improve your interface. It’s well worth the effort! Ah, and don’t forget to secure your senior management’s backing in early stages 🙂