Tag Archives: Star Wars


1. Start with Provisional Personas

As its name suggests, a provisional persona is not a fully-fledged, detail rich user model, but a first version that is good enough to start discovering the right user experience and the right product features. Working with sketchy but good enough personas is particularly helpful in an agile and lean context where we want to very quickly test our assumptions, rather spending a lot of time with upfront market research.

To get started, learn enough about the users and customers by employing, for instance, direct observation and problem interviews. While your initial personas can be sketchy, they should be based on market insight and nor speculation. With your provisional personas in place, gather feedback on prototypes, product increments, and MVPs to validate and adapt your personas. As you run more iterations, your personas should become more refined. The following picture illustrates this process:


Note that provisional personas are different from proto-personas, as defined by Jeff Gothelf, as proto-personas are not necessarily based on user research.

2. Keep your Personas Concise

It’s easy to add more and more detail as you create your personas: Enriching the description and adding, for instance, another cool spare time activity or a cute pet can be so much fun. While your personas have to contain enough information to be usable, too much detail bloats them, and they become difficult to work with.

Only include information that is relevant, that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest. My simple, minimalist persona template wanst to help you write concise personas (you can download the template by clicking on the picture):


3. Distinguish User and Customer Personas

Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see.

Say we want to develop a new, advanced X-Wing Fighter. The pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Rebel Alliance is likely to be concerned with the purchase price and the maintenance cost. Employing two different personas allows us to model the user and the buyer, and to state their different goals.

4. Choose a Primary Persona

Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, the pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal – creating a plane that’s easy to fly and well protected – becomes our top priority. But if we choose John, the purchase guy, as the primary persona, then the resulting product would be very different.


5. Make your Personas Believable

Your personas should help the development team cultivate empathy for the users and customers, and to view the product from the user’s perspective. To achieve this, your personas have to be believable. There are three practices that help you create believable personas:

  • Base your personas on user research.
  • Respectfully choose a persona’s name, picture, and characteristics.
  • Refine personas together with the development team.


6. Identify the Main Benefit or Problem

I frequently see personas that contain a lengthy list of problem and benefit statements. While is it is perfectly OK that a persona description provides more than one problem or benefit, I recommend selecting one main problem or benefit – the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making.

7. Test your Personas

Validate your persona descriptions, as you lean more about the users and customers and their needs by building prototypes, product increments, and MVPs. This is particularly useful in an agile and lean context, where you want to minimise the amount of initial market research to quickly test your crucial ideas.

Adjust and refine your personas when you decide to persevere. But rewrite your personas or start with brand-new ones if you have to pivot and change your strategy.

8. Connect Personas and User Stories

Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover. The following format helps you connect your personas with your user stories:


9. Visualise your Personas

Make you personas visible and accessible to everyone involved in the development effort. I find working with paper-based personas very beneficial, and I like to put them on the Product Canvas.


10. Recognise when Personas are not Appropriate

While personas are a powerful tool, there are instances when they are not appropriate. If you create a product that serves a small user group, then working with personas not be necessary. Similarly, if your product does not have any end users, the employing personas is not advisable.

Take a client of mine that develops a physics engine, software responsible for the clever animations in computer games. The users of the software are games developers who integrate the engine into their code. Creating personas for the physics engine is not beneficial in my mind. But for the entire game it is, of course.

More Information and Help

You can learn more about working personas in an agile and lean context by attending my Certified Scrum Product Owner an Product Canvas training course. The courses are also available for onsite delivery. Please contact me for more information.

10 Persona Tips for Agile Product Management by Roman Pichler is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Based on a work at http://www.romanpichler.com/blog/10-persona-tips-agile-product-management/.

“But with the blast shield down, I can’t even see! How am I supposed to fight,” asks Luke Skywalker in the Star Wars movie Episode IV while training with his lightsaber on board of the Millennium Falcon. “Your eyes can deceive you. Don’t trust them. Stretch out with your feelings,” answers Ben Kenobi.

This little story illustrates a fundamental question: Should we trust our intuition or our analytical abilities to make decisions?


Empirical approaches to product development such as Scrum and Lean Startup encourage us to leverage data to make decisions: We use product increments or MVPs to gather the relevant information from users, customers, and other stakeholders. Analysing the data should then allow us to draw the right conclusions and to adapt the product – to pivot or persevere. The following picture illustrates this approach:

data-driven, experimental process
If this blog post, for instance, does not attract as many comments and doesn’t generate as much Twitter traffic as I had hoped, does it mean that I must rewrite or remove it? The data alone is not going to tell me the right answer.


“If I had asked people what they wanted, they would have said faster horses.” This Henry Ford quote shows how difficult it can be for customers to tell us what they really need. As product owners, we have to be creative and envision the future product, a product that we believe will benefit its users and the company providing it.

Vision, however, is based on intuition or instinctive knowledge. It’s based on what we feel is right, aesthetically pleasing, and helpful. It’s the opposite of a data-driven, empirical approach:

vision-lead process
While using our vision to guide our decisions may seem attractive, there is a dark side: I could, for instance, follow my vision of creating what I believe would be a brilliant, amazing book only to find out after its publication that nobody really wants to read it. Time and money would be wasted, revenue lost.

Reality Check

Let’s recap: Data alone is unlikely to tell us what to do, and trusting our intuition is risky. Human beings are prone to make errors, and our intuition can be distorted by cognitive biases. Luckily, the two approaches complement each other: As product owners, we need a vision of where we want to take our product, and we should believe that the product can benefit its users and the company providing it.

At the same time, we should be critical of our ideas, and constantly ask ourselves: “Why would anybody want to use our product? Why should the company invest in it?” We should carefully analyse the data obtained form users, customers, and other stakeholders to repeatedly test our ideas and assumptions, to check that we are on the right rack, and that it’s worthwhile to continue. This is illustrated by the following picture:

intuition and data lead to a great product

So what should I do if the data suggests that this post is not as exciting to my readers as I would have hoped? It would certainly allow me to investigate the likely causes: Is the topic not particularly relevant? Did I present it in the wrong way? But ultimately, it’s up to me to decide what I do about the post, and if I continue writing about the subject. As the product owner, I am responsible for the success of the product. No clever algorithm or analytics tool will be able to make the right decision for me.


Innovation relies on our intuition as much as on testing our ideas by gathering and analysing the relevant data. As product owners, we should neither blindly trust our intuition, nor should we expect that the data answers all our questions. Instead, we should use both, intuition and data, to guide our decisions.

You may be wondering what happened to Luke Skywalker trying to block the laser shots with his lightsaber without being able to see. He succeeded, of course, and Ben Kenobi told him: “You see? You can do it.” Interestingly, Luke employed his intuition and the data available to him, that is, the rather unpleasant experience of being hit by the laser remote. In fact, the experience helped him to improve its intuition, to anticipate and intercept the shots.

Now, would it be data-driven or intuition-lead to claim that this enabled him to become a great Jedi?

“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back”. Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for many years to find out. A few minutes will do.

Why Ready Matters

The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.

If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment. It is therefore important to ensure that there are enough ready items on the product backlog. Consequently, my Product Canvas uses a dedicated ready section, as the picture below shows:

What Ready Means

A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with ScrumA story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-prtiority ones facilitates clarity.

An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.

A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days by the way, as this allows the product owner to provide feedback on the software during the sprint.

Ready stories are the output of the product backlog grooming work. To put it differently, your grooming activities should result in ready stories.

What a Ready Story Looks Like

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and  what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are simply attached to the story, as the picture below illustrates:


“A Jedi must have the deepest commitment, the most serious mind,” continues Yoda in the Star Wars episode. Similarly, you should be committed as the product owner to creating high-priority product backlog items that are clear, feasible, and testable.

Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.