Many organizations use digital transformation as a strategy to succeed in today’s complex environment. People skilled in business analysis can play a key role in applying digital technologies to create and improve business processes.
Some organizations don’t value effective business analysis in digital transformation, while others do.
To ignite your potential, you can use your business analysis skills to help any digital transformation succeed.
Attend this workshop to learn how business analysis contributes to successful digital transformations. You’ll also find out how to tell if you’re in a digital transformation in name only and find out how you can make the best of that situation.
You’ll also learn about techniques that are helpful in both circumstances.
- Discover the problem you’re trying to solve with story-based interviews
- Make informed decisions guided by decision filters and a well-formed problem statement
- Help your team deliver an effective solution with a structured, collaborative refinement process
- Understand context to properly select and adjust your approach
- Collaborate effectively to get the most out of your team.
Join this workshop to practice these techniques and gain access to helpful resources. The knowledge you gain will make you a crucial part of your organization’s digital transformation.
Transformations
Agile Transformations
Organizations used agile transformations to become more efficient, and sometimes more effective building software.
Unfortunately, in some organizations, business analysts were negatively impacted:
- An “Agile Coach” claims that Agile says no BAs (For the record agile doesn’t “say” anything)
- The organization chose to switch BAs to Scrum Master or Product Owner or eliminate BAs altogether, and later regretted it.
Digital Transformations
Organizations try to apply digital technologies to most, if not all of their processes. Placed a particular focus on exposing their processes to customers and let customers self serve.
This also led to a higher expectation that B2B software needs to have a similar experience to B2C software.
Effective digital transformations led to process improvements: While we’re applying technology to this process, let’s make it better. BAs shed light on process, rules, and data
Ineffective digital transformations resulted in Lift and shift. BAs solely responsible for writing requirements.
Product Transformations
Change how we organize work and organize our team.
Discovery
Don’t elicit requirements. Elicit stories.
Product Market Fit Pyramid
From Mastering the Problem Space for Product Market Fit by Dan Olsen
- Target Customer – who are we trying to create value for?
- Underserved Needs – for that target customer, what are their needs?
- Value Proposition – your hypotheses about which customer needs your product addresses, how the customer benefits from your product, and how you meet their needs better than other products
- Feature Set – the functionality that conveys those benefits to the customer
- User Experience – what the customer interacts with in order to receive the benefits
Taken together, the first two layers – target customer and underserved needs – are the market. You don’t control the market – you can choose which customers and needs to target but you can’t change those needs.
What you do control are the decisions you make at the next three layers in the pyramid – the product.
Don’t make your interviewees lie to you.
Ask them to tell you stories of what they’ve actually done. If you ask them to anticipate what they’ll do, they will lie to you (unintentionally). People are notoriously bad at predicting the future.
For more info on the good advice and even better advice for doing interviews where you elicit stories, see Teresa Torres’ Story-Based Customer Interviews Uncover Much-Needed Context.
In an article about user interviews, I suggested how you may let context guide your user interviews.:
Creating a new product
When you’re creating a new product, you may interview potential customers and users to uncover what problems they value solving or how they’re currently solving the problem you’re trying to tackle.
Optimizing an existing product
When you’re optimizing an existing product, you interview users to get a better understanding of how they currently use your product, or identify what problems they have that your product could also solve.
You may interview people who stopped using your product to find out why. You could also interview people who aren’t using your product yet to determine what they do to solve the problem you’re addressing.
Replacing an existing product
As I hinted at above, when you’re replacing an existing product, you need to get a handle on how people are currently using your product. You’re especially on the lookout for novel (a kinder way of saying “weird”) uses.
Taking notes for your interviews:
Teresa Torres also shared a nice format for collecting notes when you do user interviews called the Interview Snapshot.
But to be honest, I don’t always get the chance to use the snapshot to take notes, or even take notes all. It’s odd to be scrawling down notes when you’re interviewing users in the middle of a warehouse. Here’s my story of when I tried to do that.
Jobs To Be Done and Interviews
It can also be helpful to look at user interviews through the lens of Jobs To Be Done. I put some thought to that after reading When Coffee and Kale Compete by Alan Klement and wrote my thoughts down in What Jobs to Be Done teaches us about interviews.
Looking back, the four things to consider should sound familiar:
- Why are you doing the interviews? (Your research question)
- Who are you going to interview? (Filtered users that have experienced what you want to talk to them about)
- How should you interview them? (Ask them to tell you stories)
- What information do you want to get? (Stories and a guide to typical behaviors.)
Decisions
If you choose not to decide, you still have made a choice
– Freewill, Rush
Decisions in three horizons
I originally described decisions in three horizons from the perspective of the Agile Extension to the Business Analysis Body of Knowledge, but in effect, all product people make these types of decisions.
Here’s a quick list to some techniques you can use for each of the decisions listed here. We covered some techniques in the session.
Is It Worth It?
Create, Change, or Pass
What solution will satisfy the need
Build vs buy
What aspect of the solution should we deliver and in what order?
Continue, change, or cancel the initiative
How do we build and deliver the solution
Do we have enough to deliver
- Definition of done
- Examples
- Acceptance criteria
Decision Filters
Decision filters are based on strategic direction or objectives and provide a simple communication of intent to guide decisions in a distributed fashion. Decision filters are questions that can be answered yes or no.
Some additional notes about decision filters:
- If in a situation that is not easily measure replace objectives with decision filters
- Use decision filters for decisions at multiple levels of planning
- Decision filters need to be actionable.
- Decision filters need to be filters (clear yes or no).
Guiding Constraints
The constraints matrix is a quick way to show the relative importance of a set of constraints facing a project team. Each row represents a general constraint faced by most teams. The most common set to use are: Cost, Time, and Scope (ie the Iron Triangle).
The columns represent the amount of change that can be accepted for each constraint when trying to deal with an overall project change.
- Fixed: no changes are desired in the constraint unless all other options have been exhausted.
- Flexible: a change can occur in this constraint only after the options that made changes in the constraints marked accept are exhausted.
- Accept: the constraint is the first place to adjust to account for a change in the project.
Some additional rules for using the Constraints Matrix:
- Each constraint can be in only one column Fixed, Flexible, or Accept.
- There can be only one Fixed constraint
- There can be only one Flexible constraint.
Decide who decides – DACI
While I’m a big fan of collaboration, getting too many people involved can slow things down, especially when you’re trying to make decisions. That’s why I like the DACI model for identifying the essential people involved in making decisions.
The bit I find most helpful is explicitly identifying who makes sure a decision happens (the driver) and the one person who ultimately makes the decision.
Build vs Buy
An extremely important, and often overlooked, decision is whether you should build or buy your solution. More often than not, organizations not only jump to a solution without understanding the problem, but they also build when they should buy, and vice versa.
Purpose-based alignment is a great way to avoid that silliness.
Rich Mironov explained how to approach the build vs buy decision in a slightly different way, that still factors in corporate strategy.
Problem Statement
It’s not enough to just ask “what problem are you trying to solve?” and expect a helpful answer. The problem statement is a facilitated exercise that helps you identify when everyone isn’t on the same page with what you’re trying to accomplish and hopefully helps you get everyone aligned.
Delivery
Forget outcome vs output. You deliver output to achieve outcomes.
Impact Mapping
Need some help “working backwards” from an outcome to identify outputs? Impact mapping is a great technique that will help you to do that.
The real powerful aspect of the impact map is that it provides clarity on how specific outputs should help you reach an outcome.
Story Mapping
There are times where you know what you need to build (for example if you’ve decided to rebuild an existing product). Or if you need to break down the thing you’re trying to build in smaller bits and consider different options which may or may not be necessary.
A story map is a helpful technique for both of those situations.
Example Mapping
If you’re looking for a collaborative way to spice up your discussions about backlog items, and clarify things at the same time, try Example mapping.
This is an especially helpful technique if you’ve ever found yourself asking “do you have an example of that?” or thinking “an example would be handy right about now.”
Organizing Teams and Organizing Work
If your organization is serious about moving from a digital transformation to a product transformation, you’ll most likely change how you organize your teams and organize your work.
Melissa Suzuno shares some advice from the ProductTalk community about how to shift from functional teams to value-driven teams.
John Cutler suggested a different approach to structuring a quarter so that you don’t feel like you’re on the sprint hamster wheel.
Context
Context is not an excuse for why you can’t transform. It’s something you consider to make your transformation successful.
Type of product drives the practices you use
When you work at a tech-enabled enterprise in an industry such as financial services, insurance, retail, or healthcare, you often work on software that enables some business process, aka an internal product. You need to have a general understanding of how this product will help your organization serve its customers, but you’ll also need to understand your organization’s processes, rules, and data. Business analysis techniques are helpful here.
You may work on your organization’s website or mobile app. It’s something your customers are going to use to buy your product, and it’s also something that helps people inside your organization with their activities. You’ll need to understand your customers and your organization’s processes in this case.
Rich Mironov did a fantastic three article series on the product management skills that product owners (and business analysts) should have.
- A Product Management Skills Map For Product Owners (#1 of 3)
- Product Management Skills For Non-Revenue Product Owners (#2 of 3)
- 5 Market-Facing Skills for (Some) Agile Product Owners
The stage in the product life cycle drives the practices you use
The product lifecycle is the journey each product takes from the inception of an idea through to a product’s retirement.
The lifecycle comprises five stages, each of which drives differences in how you manage your product.
During the development stage, you and your product team simultaneously perform discovery and delivery to identify the problems you’re trying to solve and create solutions for those that are worth solving.
Once you hit the introduction stage, you release the initial version of your product to the market for testing and iteration, so that you can find product-market fit.
When you’ve found product-market fit, you move to the growth stage. Here, your product has proven adoption and traction, and you can focus on increasing market share.
You enter the maturity stage when growth and rapid customer acquisition level off, your product enters the maturity stage. The focus of this stage shifts from growth to retention.
The decline stage is where demand for your product has reached its peak and is declining. You need to decide whether to pivot, revitalize, or sunset the product.
Uncertainty and complexity drives the practices you use
C
Then there are some characteristics of both your product and organization that combine to add context – complexity and uncertainty.
The Context Leadership Model, created by Todd Little, was introduced in Stand Back and Deliver as a tool for determining the appropriate leadership style given your product’s uncertainty and complexity. You can also use the Context Leadership Model to understand the risks inherent in a product. That will help you determine how to approach analysis and documentation to address those risks. Todd represented each quadrant with an animal whose characteristics mirror those of the products that fit into that quadrant.
Here’s a Google Sheets template you can use to assess the uncertainty and complexity of your product. Feel free to make your own copy and give it a whirl.
Collaboration
Software product development is a team sport
The Product Trio in practice
The product trio is a common collaboration pattern for software product teams:
- A product person paying attention to whether a solution is valuable (solves a customer problem) and viable (good for the business)
- A tech lead paying attention to whether the solution is feasible (can we build it)
- A designer paying attention to whether the solution is usable (can people use it)
However, not every solution has direct user interaction, so a better formulation may be to abstract out “designer’ to the person who’s best suited to deal with the biggest risk facing the product/company.
Hat tip to Chris Matts for pointing out that broader view of the trio.
How to work with Engineers
As Debbie Widjaja matured in her understanding of product management, she realized that trying to keep all engineers happy is a sure way to be a miserable PM. A product manager should be a multiplier of the engineers on a product team. To quote Liz Wiseman: Multipliers are the leaders who use their intelligence to amplify the smarts and capabilities of the surrounding people. Debbie created an acronym – ARISE – to describe how she works with engineers.
How to work with Designers
And while I just said that the designer may not always be the third member of the product trio, they often are, so it’s helpful to know how to work well with them.
There can be quite a bit of overlap between product manager and product designer skill sets, so it’s important to establish clear expectations about who is going to do what and where you’ll work on the same thing together.
To help you keep on the same page, here’s a collection of tips for building a strong product manager – product designer relationship.
Retrospectives – a powerful tool for team collaboration
If there’s any technique that I’d use from agile approaches regardless of the mode I’m working in, it’d be a retrospective.
Here’s my favorite approach to facilitating action focused retrospectives to make sure those