Simplicity in Design Meets Agile and Lean Startup Principles

If you have been following my previous posts, you will see a focus on the culture of experimentation and thinking loudly with your team and potential customers about the need for your product and its value. This culture of experimentation is not new and has been emphasized in Lean methodology over and over to avoid waste and maximize the business value of your development efforts.

To make the best out of Lean and Agile worlds, product development heads have invented what is called Design Sprints, which are time-boxed activities that push us to brainstorm, test and iterate over our hypotheses in the very early days of product development.

But how is that linked to simplicity in design?

simplicity

If you have 10 features to add to your product, you need confidence to decide what to keep and what to remove to keep it simple, and confidence comes from your understanding to your customer and the rigorous experimentation you do before introducing new features. Otherwise, you will find simplicity is impossible to achieve in the sense of making the right set of focal choices for the user.

Getting Lean-er with Value Hypothesis – Product Case Study Part 4

In the previous post, we learnt how to systematically validate our hypotheses about persona and problem scenarios. Now, we need to make sure we have a proper value proposition to address our persona problems, needs or desires. And the questions is: Are we providing a better alternative to what the user currently has? Will they be motivated enough to abandon other alternatives and join us?

The evangelist Guy Kawasaki once told a story about Sony and its experience with the yellow walkman. You can check it out here.
The moral of the story is that you shouldn’t present your potential customer with a solution and ask them about their opinion. They will almost always give you an affirmative reply! They will always say “yes” for a feature or product but they might not mean it. Instead, you need to observe your user behavior and response, and measure them against your value proposition, assumptions and metrics. Continue reading

Getting Lean with Persona and Problem Scenario Hypotheses – Product Case Study Part 3

In a previous post of this series, we brainstormed to create hypotheses about User Personas, Problem Scenarios and Value Proposition. We also created User Stories to drive narrative collaboration about our product.

Here, I’m going to show you how to get out of the building to understand what problems, desires or needs do your users care about. And I’m going to use user personas, which are ways of describing those users, and problem scenarios, which are ways of describing what is actually important to them.

This activity must be time-boxed so we constraint the time we have to push ourselves to focus and experiment and not go astray on extraneous details. Usually these experimentation exercises are called Design Sprints and they are limited to 5 days each. Does this remind you of agile practices?! Before committing to any expensive investment, you take your idea to the market and start experimenting with your hypotheses and creating refined user stories, if not pivoting the whole idea if users show no interest! Continue reading

User Stories that Drive Narrative Collaboration – Product Case Study Part 2

In Part 1 post of this series, I started with an imaginary conversational travel assistant product and demonstrated how to create its Persona and Problem Scenarios .  I also introduced the Value Proposition concept as a better alternative/s to the exiting alternative/s.

In this post, we will continue our case study to learn how to create and use them to drive narrative collaboration, which is at the heart of successful agile practice.

Fogg Models

According to BJ Fogg’s Behavioral Model, the most important elements to getting the user to act and use our product are Motivation and Usability. We will cover Motivation (Value Proposition) in details in the coming posts, while in this post we will focus on Usability and creating a good user experience through stories. Continue reading

Putting Persona and Problem Scenarios Together – Product Case Study Part 1

In my previous posts I talked about brainstorming to create a vivid and alive description about Product Personas that helps us imagine the persona in real life and what they do, think, feel and see to operationalize them in the context of product development.
We also discussed creating Problem Scenarios and alternative pairs to make sure we are creating a better alternative (value proposition) that addresses an existing and real-life problem, need or desire that our persona has.

This post marks the start of a series that demonstrates a tested lean and agile process to create a successful software product and leverages on previous posts. So let’s get our hands dirty and start with a real life product: A conversational travel assistant!

Project Description

Let’s first define our project which we will iterate over throughout the coming posts. It is just a brief that covers the bolded points and helps our collaborators get a very good idea about the product we intend to build.

For [tourists] who [travel to new destinations or would like to further explore known destinations], [TravInfo] is a [conversational travel assistant] that [provides users with pre-travel advice on their place of interest and keeps sending them updates on the go as they visit places]. Unlike [TripAdvisor and tourists blogs], our product [provides information with minimal effort from the user and without spending hours reading up on the destination to compile knowledge about its attractions and interesting places]. Continue reading

Problem Scenarios and Creating Value for the User

After defining our product personas and before proceeding with other product development activities, we want to make sure that the problem or the desire we are addressing at the feature, product or company level exists! Otherwise, we will end up with a software or features that nobody cares about.

As a product manager, you want to avoid just adding features to the product because you will run into many situations where every stakeholder has a “killing” feature to add and will make your product awesome, specially salespeople 🙂

The alternative is being diligent and observant about our users and what they really care about, and to create problem scenarios and alternatives pairs. To illustrate, I will give an example from my current position at work: Continue reading

Creating a Product Persona – The Infrastructure of a Successful Product

Many product managers try to build a product for the largest audience thinking that it will help them grow their user base rapidly and show significant growth to their business stakeholders. 

In my opinion, this is the fastest way to failure and to deplete your precious resources specially at the initial rounds of investment. And here where the idea of persona comes to the rescue. There are many posts on the internet about creating personas, mostly published by marketers who have marketing as their first interest when they create a persona.

In this post, I’m going to tackle this subject from a product development point of view, and will walk you step by step until you create a fully fledged persona. Continue reading