Tag Archives: Agile

Monolithic vs Microserivces Architecture from a Product Manager Perspective

Posted on by

Monolithic vs Microservices systems is now a hot topic that a product manager will probably encounter when they tune their interface with the development team.

What is a monolithic system?

In a nutshell, your system is called a monolith when you have all components like authentication, authorization, product catalogue.. etc in the same codebase.

What is a microservices system?

Instead of having a single codebase that has all your components, you have a web of individual codebases and individual services that work together to deliver the application.

Usually, when you move to microservices, the importance of testing goes up dramatically Continue reading →

Integrating OKRs With the 0, 30 and 90-day Rule to Measure Product Success

Posted on by

What is OKR?

OKR (Objectives and Key Results) is a goal setting system used by Google and other companies. It is a simple approach to create alignment and engagement around measurable goals.

I will (Objective) as measured by (this set of Key Results).

OKRs originated at Intel in the late 90s and was introduced to Google in 1999 by the famous venture capitalist John Doerr, and continued to spread to other companies in the Silicon Valley. It has supported Google growth from 40 employees until now!

I will not explain OKRs in details as there are many online resources for this purpose. I will, however, show you how I integrated this framework with the 0, 30 and 90-day rule to achieve product success and to ensure everyone is going in the same direction, with clear priorities, in a constant agile rhythm.

What is the 0, 30 and 90-day Rule?

It is a test criteria used in Agile development to test different stages of product adoption by target users (personas): Continue reading →

Qualitative vs Quantitative Research in Product Management

Posted on by

It is a lot of work to get started and to figure out what you should do and when. Here I would like to talk about the distinctions I make between triggers that tell you, right now you need qualitative research vs right now you need quantitative research.

Let me break it down:

  • Quantitative research, quantitative metrics, numbers, analytics tell you what is going on with your product.
  • Qualitative research, talking to people, observing their behavior tell you why those things are happening

Continue reading →

Thoughts on Traditional vs Agile Project Management

Posted on by

Traditional project management has been practiced and enriched over decades in different domains such as construction, defense, technology… etc. Most of the literature like PMI and PRINCE try to formalize this discipline and focus on giving it clear steps that you follow from start to the end of the project.

Scope is in the heart of traditional project management

time-cost-quality-model

Being PMP certified and an early adopter of Agile and Lean principles, I felt like flipped on my head Continue reading →

User Stories that Don’t Kill Creativity and Collaboration

Posted on by

What is fascinating about the User Story is that it’s an open-ended framework that can be used well or it can be used poorly. The most important thing is keeping the User Story in problem space and to link it back to your value proposition and problem scenarios. Two reasons for that:

  • It helps to debug when something goes wrong by tracking back to the origins of the story and what problem it meant to address
  • It facilitates the important discussion with the team so they can reach a shared understanding of what the problem is and together conclude what is the best way to solve it

Continue reading →

Stories or Tasks on Kanban Sprint Board?

Posted on by

I often get asked by Agile teams what should go on a Kanban board during sprint planning. The short answer is: It depends on what works well for you as long as you are maintaining the spirit of the methodology by keeping everything visible on the board and “Just-in-time”.

Some companies focus on recruiting highly qualified full stack developers that can work on different areas such as database design, business logic, front end, testing, integration.. etc. In this case, I believe the best option is to use only user stories on the Sprint board. Each developer will be able to handle a full user story and move it across the Kanban board as a one coherent unit which reduces the overhead of handoffs and coordination with other developers. Also it makes easier for the product owner to verify a full user story rather than trying to combine multiple tasks together to create a testable narrative. Continue reading →

Simplicity in Design Meets Agile and Lean Startup Principles

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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 →