I love using personas for my own products and in my client-facing work. But for quite some time, I was looking for a good template that allows me to effectively capture the relevant information. After experimenting with different approaches, I believe I have come up with a helpful format, which this blog post introduces.

Personas in a Nutshell

I was recently helping a client with a new product to be developed for an existing market. When the team began sharing all their ideas about features and functionality, my head started to hurt. So I stood up, grabbed a pen, went to the flip chart, and asked: Who do you think are the users of the new product? And what are their main characteristics and their needs? In no time had we come up with preliminary personas: fictional users and customers.

The great thing about personas is that they invite us to view the product from the user’s perspective. This helps us design a product that truly benefits its users. It avoids getting stuck in longwinded discussions about features, features, and more features. It allows us to explore if a feature would actually benefit one of the personas. Think about all the products you have come across where you asked yourself why the product is so difficult to use. Chances are that the people responsible for creating it did not carefully walk in the user’s shoes. Take the struggle I had this morning with our dishwasher: One of the clips that attaches to the tray had come lose. Clipping it back in turned to be fiddly and difficult. The design must have been optimised for production, and not for the user.

Working with personas implies a user-centric approach: We have to put the user first, and build a product that wants to do a great job for the user. As a consequence, the product becomes a means to an end. It exists to serve its users.

A Persona Template

There are three pieces of information I have found particularly important when working with personas: First, the persona’s picture and name; second, the relevant characteristics such as demographics, lifestyle, and job-related information: third, the need that the persona has or the problem that the product should solve. I therefore use the following structure to describe a persona:

The first two sections in the template above describe who the persona is. The last one is particularly important, as it makes us ask why the persona would want to purchase or use our product: The needs are often more important to develop a great product than the demographics.

Here is an example of how the template can be applied. It features a persona of a new book I have recently started to work on:

Notice that I have tried to make the persona description as relevant as possible. I have left out information that is not essential to understand who the character is and why the person would want to read the book. For instance, I decided not to include Peter’s marital status. At the same time, I have tried to be as specific as I can right now about the persona, so I can validate my assumptions. As I find out more about the target readers of the book, I will undoubtedly iterate over Peter’s description, and update it. While refining your persona, ensure that the character is believable and that its description allows you to develop empathy for it. You can do this, for instance, by adding pictures, likes and dislikes to the characteristics.

Visualising Personas

I prefer to capture personas on paper, so I can easily visualise them by pinning them on the wall or the product vision board, as the picture below illustrates. An A4 or A3 sized paper sheet usually does the job.

Another big advantage of using paper-based personas is the limited space available. This helps to focus on the relevant information rather than writing everything down we believe to know about the user.

Summary

Personas are a great technique to capture information about users and customers. They help create a product that serves its user. Employing the persona template introduced in this post helps us capture the relevant information and focuses our effort. With preliminary personas in place, we can start to explore how the needs can be best addressed, create a first prototype, and test our assumptions. I will write more about using personas in an agile context in one of my next posts. So stay tuned ☺

If you get a chance to experiment with my persona template, then I’d love to hear from you! Write a comment, tweet or email me.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

The role of design still puzzles many Scrum and Kanban teams I work with. When should the design activities take place? Who should carries them out? How are design decisions best captured? This blog tries to answer the questions by introducing my preferred design approach.

User-centric, iterative, and collaborative

The image above depicts the design process I employ. It’s user-centric, iterative, and collaborative. The process starts with capturing the design concept in form of a rough mock-up. Then the detailed design for one or more user stories is created and implemented as a throwaway prototype or as shippable software. The result is exposed to the users to understand if the design contributes to a great user experience. If it does, the design is refined, and the design for the next stories is created; if it does not, the design concept is reworked.

High-level Design

To get started, develop your design concept. The concept should sketch your key design ideas and communicate the essence of what you believe the product should look like. This includes the shapes and the colours you intend to use. Keep the overall product vision in mind together with the desired user experience: the kind of product being developed and the reason why people might want to use it. Focus on the critical aspects and don’t worry about the details right now.

For instance, the high-level design below shows how the structure, shapes and colours of our new homepage together with a photo of a bald guy with a beard and sticky notes.

High-level website design

Capture your design concept as a mock-up. Consider using a paper sketch similar to the one shown above. Paper sketches require less effort than wire-frames or other mock-ups; they are usually good enough to communicate the design idea. Make your sketch visible and put it on the product backlog board as shown below.

High-level design on the product backlog board

You may also want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model area. (You can find out more about the backlog board in my blog post “The Product Backlog Board“.)

Detailed Design

With your design concept in place, create the design for each user stories you want to implement. This is best done as part of the product backlog grooming work. Developing the detailed design should hence be a collaborative exercise that involves the developers and testers. This allows you to leverage the team’s collective creativity and to quickly discover which design options are difficult and expensive to implement.

Sketch the user story-specific design on a paper card and attach it to the story card, as the image below illustrates. The design depicts the details of one of the boxes on the homepage:

Detailed design for a story

Then implement the design either as a throwaway prototype or as shippable software, and expose the result to the users. Note that paper prototypes are often sufficient to test your initial design ideas. Resist the temptation to create a perfect design straight away: An unpolished implementation tends to generate more valuable user feedback than a super slick design.

Learning

Leveraging the user feedback to validate your design ideas does not mean that you don’t require a vision of what the product should look like. The opposite is true. You have to innovate for your users and cannot expect to be told what the product should look like.

Take the redesign of our website for example: Our customers, the organisations that pay for our training or consulting services, are important users of our website. Most of our customers are mid-sized to large enterprises. Having worked for large companies myself, I know that bigger organisations often prefer a more conservative look. But we wanted to create a website that that looks cool and that we like, not a boring corporate design. The challenge is hence to synthesise the wants and needs of the users and your own vision and ideas into a great design.

Synthesising needs and vision

Use the feedback to experiment and discover which design ideas don’t work and which do. Don’t be a slave to the feedback, but don’t cling to your ideas either. Analyse the feedback with an open mind and decide what to do: take it on board or discard it. Then either rework your design concept or adjust it, and create the detailed design for the next story.

Summary

Creating the design iteratively, taking advantage of the team’s collective creativity, and leveraging user feedback to validate design ideas maximises our chances of developing a product that with a great user experience, a product that users love. Happy designing and please let me know if my thoughts are helpful. I look forward to your comments!

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

Getting lost in the product details and struggling to decide if a feature should be implemented is a common challenge for product owners and product managers. It’s something that happens to me all the time, even while I was writing this post. But as product owners, we should focus on what really counts: creating value for the people using the product and the organisation developing it.

What’s in it for the User?

Some product owners I work with worry too much about how to write a certain user story or what the detailed design of a screen should look like. Whenever this happens, I find it helpful to step back and ask the following questions: Why would anybody want to use the functionality? Why would a certain design be helpful?

I know the image above looks pretty trivial. But it took me a few iterations to create it. I started out with a more elaborate design, which I dropped after I reflected on the desired user benefit: Glancing at the images should allow the reader to understand the gist of the blog post. Selecting a simpler design hopefully achieves this goal better.

The Product is a Means to an End

Exploring how a story or design idea benefits the users means viewing the product as a means to an end: to serve the users as well as the organisation creating it. As marketing guru Theodore Levitt famously put it, “People don’t want a quarter-inch drill, they want a quarter-inch hole.” What really matters are the benefits the product provides.

I find that personas and scenarios are great to hypothesize about the users and their needs. A persona allows us to capture assumptions and ideas about what a typical user might be. The scenarios describe the user’s problem, how our product should benefit the user together with the desired user experience.

While serving the user should be the primary purpose of your product, you shouldn’t forget about the value the product has to create for your organisation. To do so, reflect on the business model that will help you achieve your business goals. This includes identifying the revenue streams, the sales channels, and the cost structure. A great tool to analyse and improve your business model is the Business Model Canvas created by Alexander Osterwalder and Yves Pigneur.

Be aware that your business model can have an impact on the product functionality: For instance, if you plan to generate revenue through online ads, then this requires the capability to place ads. As a consequence, an ad epic will appear in your product backlog.

To capture your ideas about user needs, the product, and the value created for the company, you may want to try my Product Vision Board. The board captures assumptions about the target group, the user needs, the top three features, and the key business model elements.

Users Come First!

If you find it difficult to balance meeting the user needs and creating value for your organisation, then focus on the user. If your product is desirable, you are likely to find a way to make money. Users should come first, money second.

Summary

Next time when you get stuck in the product details, zoom out. Ask yourself how a feature adds value for the users and your organisation. Then implement it, gather the relevant data, and check if the benefit has been realised. Happy developing!

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” or incubator within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.

A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.

The Scrum Startup

An Enterprise Scrum Startup

The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.

We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a vision for the new product and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.

We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and which is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.

Autonomy

Setting up a Scrum team as an incubator is so powerful as it disentangles the team tasked with innovating from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.

The Scrum Startup and the Enterprise

The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things, and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.

Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.

Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.

Collaboration

As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.

Scrum Startup and Collaboration

When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.

Scrum Startup Qualities

To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the incubator should be stable. The following image depicts the four qualities:

Desirable Qualities of a Scrum Startup

Summary

Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as an incubator can facilitate product and process success. Give it a go, and let me know how it’s working for you.

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler

I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test our ideas as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.

Build, Measure, Learn

With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum.

But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?

This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.

The Product Vision

“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction.

To reach our goal, we have to decide on an approach or strategy. This includes making assumptions about the target group, the needs the product should address, the key product features, and the value it should create for the organisation developing. I use my vision board to capture and visualise the product strategy.

The strategy’s assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to the target customers and users.

The Product Backlog

Unfortunately, the product strategy is often too coarse-grained and partial to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the strategy.

The corresponding items are placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product strategy; it makes the strategy implementable.

Vision, Product Strategy, Product Backlog

From Backlog to Minimal Viable Product

Once we have a strategy and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the relevant data.

Strategy, Backlog, and MVP

Note that releasing the MVP can be limited to a small group of users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. A counter example is Google Buzz: The software was apparently loved by Google engineers, but unfortunately not by the rest of the world.

Pivot or Persevere?

Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions in the product strategy – which is likely to be the case when a new product is developed – we should adjust it together with the product backlog. Making changes to the strategy is also called pivot.

We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the product strategy can require restocking the backlog. With the backlog updated, we continue with the next cycle, develop a new MVP, and gather new feedback.

Pivot

If the data confirms our strategy, we preserve and adapt the product backlog by incorporating the insights gained. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.

Persevere

Summary

Using a minimal viable product is a powerful concept to validate the product backlog that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations. Many thanks to @stefanroock for feedback on the first MVP of this post.

If you’ve found this blog post interesting, you are likely to benefit from my Agile Product Management training. The course teaches a combination of Lean Startup, Scrum, Kanban, and Design Thinking techniques. Check it out!

Roman Pichler - Roman Pichler's Thoughts on Agile Product Management Roman Pichler