What is a Munro 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 system card that is used during the road mapping workshop. The details of the card are up to you and the context your are working in.

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

• An ID reference

• The initiative 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 product(s), platform(s), or channel(s) that the initiative may involve.

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

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

• Metrics

• Definition of done

• Acceptance criteria

• Risks

• Assumptions

• Issues

• Dependencies

• Or any other notes that you capture during the workshop.

You could also use a 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> 

* Must incorporate who is it solving a problem for/who benefits from it – 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 firstly creating a "POV Madlib" 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… in order to thrive and grow in a healthy way."

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 suggest 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 regarding the implementation of the solution. The problem statement 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 easily feel daunted. 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 get better at it and with more people collaborating on it you'll get a good result.