Munro Action Card

A Munro Card is used to quickly show information about an initiative to be placed within a Munro Map.

A typical Munro Card is a system card used during the road mapping workshop. The details of the card are up to you and the context you are working in.

Below is an example of the front side of a Munro Card. Basic information includes:

• An ID reference

• The action name

• Estimated size (usually T-shirt sizes when estimating large things into the future)

• A short description (keep longer descriptions somewhere that everyone can access, e.g. a wiki)

• The initiative may involve the product(s), platform(s), or channel(s).

• and any other information that makes putting the card within a map easier, e.g., a deadline or other constraints.

The back of the Munro Card can incorporate other notes you may identify during the process. These notes are not as important to know while creating the Munro Map but will be important later on. Information could include things like:

• Metrics

• Definition of done

• Acceptance criteria

You could also use the Goal Oriented Product Roadmap (GO Product Roadmap) template from Roman Pichler. https://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/

Or as a hypothesis using a template like...

We believe that if we <deliver/implement/provide> <this change from the current state to the future state, X changes/provides/gives/updates Y>
(Then) we will be able to <discover/test/demonstrate> <this outcome> 
We will know we have succeeded when <we see/do/earn/produce etc. (metrics). – could be a set of bullet points> 

* It must incorporate who it is solving a problem for/who benefits from it—this could be in the outcome or the metrics. 

Or as a problem statement like this...

So that (benefit)
how can (we - our team name)
do (something) for (customer)

Or, first, create a "POV Madlib" and then a "How might we" statement like this (see https://www.interaction-design.org/literature/article/define-and-frame-your-design-challenge-by-creating-your-point-of-view-and-ask-how-might-we).

POV: [User . . . (descriptive)] needs [Need . . . (verb)] because [Insight . . . (compelling)]
Example: "Teenage girls need… to eat nutritious food… to thrive and grow healthily."

HMW: How might we...
Example: How Might We make healthy eating appealing to young females?

Other variations: 
* In What Ways Might We…. (Expand on HMW to add the possibility of multiple ways.)
* What's stopping us from...?
* In what ways could we...?
* What would happen if...?

www.interaction-design.org also suggests that a good initiative problem statement should be:

• Human-centred. This requires you to frame your problem statement according to specific users, their needs and the insights that your team has gained in the Empathise phase. The problem statement should be about the people the team is trying to help rather than focusing on technology, monetary returns or product specifications.

• Broad enough for creative freedom. This means that the problem statement should not focus too narrowly on a specific method for implementing the solution. It should also not list technical requirements, as this would unnecessarily restrict the team and prevent them from exploring areas that might bring unexpected value and insight to the project.

• Narrow enough to make it manageable. On the other hand, a problem statement such as “Improve the human condition” is too broad and will likely cause team members to feel daunted easily. Problem statements should have sufficient constraints to make the project manageable.

This is why it is so hard to get this right! Don't worry. With time, you'll improve, and with more people collaborating, you'll get a good result.