Life of a Business Principal in Consulting

Scaling a Program

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 04 Apr 2019 04:15:00 +0000

Lead and Lag Measures

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Tue, 12 Mar 2019 01:14:00 +0000

Outcome based product management seems to be taking off.

Along with Hypothesis based development, this has turned around product development from detailed product roadmaps that we used to have to more customer and user focussed product development.

However, We seem to fall under the trap of Build-Measure-Learn and not measure the right things.

A lot of times, we measure lag indicators that do not help us learn faster. Lag indicators are history, they tell us what we did right and wrong post-facto after the event has happened.

We need a way to understand and measure how features can go into a product roadmap as we are building it or as we are considering it.

Lead measures help us with that.

Darwin's theory of evolution and being an idea evangelist

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Tue, 26 Feb 2019 18:44:00 +0000

Charles Darwin’s theory of evolution is best known for its quote on the survival of the fittest.

The accurate Darwinian quote is as follows:

Survival of the form that will leave the most copies of itself in successive generations.

In Consulting , when we facilitate large group conversations, It becomes very difficult to herd every one together and try to channel their thoughts and ideas to one single conclusion.

Similarly , when we run large programs of works, it becomes very tricky to introduce change and make it stick.

My experience has been to use the most famous and least understood idea of the “the survival of the fittest”.

How to handle a cranky team member

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 21 Feb 2019 21:23:00 +0000

Scenario:

You have been working on a team where a team member has been throwing tantrums on every decision made.

He has been involved in some of them but claims to not be engaged. He keeps complaining of not being kept in loop, does not react positively to feedback and generally shirks responsibility.

These are symptoms that something else is wrong.

How do you go about managing this scenario?

Using System Archetypes for taking effective action

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Tue, 03 Apr 2018 14:00:00 +0000

Organisations go through a lot of change and the predominant cause of these changes is growth. Every organisation would like to grow - though the dimension of growth would depend upon the purpose of that organisation.

One of my responsibilities as a Business Principal is to understand what growth brings to a specific organisation and how it can impact if the specific actions taken is not mapped in context for future.

I had an opportunity to facilitate an exercise for senior leaders in my organisation that had come together to make sense of an organisation-wide study of processes. There was a lot of chaos in the room since there was no one lens through which to view the findings of the study.

We used a simple system archetype called "Growth and Underinvestment". This post is a quick experience report on running the exercise for the team.

Designing Anti-fragile Systems - Case study: Uber Autonomous driving Accident

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sat, 24 Mar 2018 04:38:00 +0000

In my previous post, we discussed principles that can be used for designing Anti-fragile systems.

There were some feedback that the case study was not easy to relate and understand the principles better. With the spirit of making it easier for all of us - including me - to understand, I am taking a very recent and relevant case study to understand Anti-fragile systems.

Principles for developing systems that are anti-fragile

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 15 Mar 2018 08:36:00 +0000

I have been trying to make sense of what anti-fragility means and how do I use that in my day job.

As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision.

I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development.

For more reading on Daniel Russo, here is his profile: http://djrusso.github.io

More reading from his paper here: https://www.sciencedirect.com/science/article/pii/S1877050916302290

This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision.

I liked the approach of principles for developing systems that are anti-fragile. It is a very valuable framework or lens through which I can view and design a program of work or a system.

Facilitating Appreciative Inquiry - Mapping user feedback to business goal

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Tue, 06 Mar 2018 15:44:00 +0000

A part of my responsibility as a Business Principal also involves facilitating conversations on end user feedback and how it maps to business goals.

There are several tools to map end user feedback to business goals. However, the intent is to understand how users perceive a business goal.

We designed a more engaging exercise that can lead to more detailed inquiry on how the business goal impacts the end users. This post is a quick experience report on facilitating an exercise Appreciative Inquiry that helped us in this intent.

A Business Principal's guide to Machine Learning - Solutioning

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sat, 17 Feb 2018 16:42:00 +0000

A Business Principal needs all the tools and techniques that is available for solutioning.

With Machine learning emerging as a key trend in the upcoming years, it makes more sense to understand how to use it for solutioning.

I have used a lot of the material for this post from here:

The Step-By-Step PM Guide to Building Machine Learning Based Products

A Business Principal's guide to Machine Learning - The origins

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sat, 17 Feb 2018 08:38:00 +0000

As a Business Principal, I have been coming across the term Machine learning for a long time. Several business executives have wondered what this animal is and how does it help them.

The series of posts is to list out what Machine learning means to a business principal and some basic industry standard approaches that has been tried out in the past few years.

Organizational growth and turn over

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Wed, 14 Feb 2018 05:00:00 +0000

Organisations need to grow. However, they should not grow for the sake of growth. That would be a virus. Orgs should not grow to survive as well. Orgs should grow with a purpose.

Team Leadership in self-organised teams

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Tue, 13 Feb 2018 07:04:00 +0000

Team leadership in self-organised teams

In a typical self-organised team, Team leadership is not appreciated. However, there are going to be instances when you would need this capacity and have to understand how to appreciate and inculcate this important characteristic as well.

Design Sprint and Dual Track Development

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Fri, 20 Oct 2017 05:47:00 +0000

Context

The current typical model of starting a large program is to have a discovery workshop for the program followed by detailed project inceptions. The project inceptions are spaced and detailed.

There are not a lot of discovery workshops we do that is mutual discovery. It is more of sense making of an earlier discovery process.

The Pitfalls and some thoughts

With the discovery process feeding into the project Inceptions was great. it gave direction. However, validation of the direction based on feedback from projects seems to be missing.

The reason the feedback is missing is 2-fold:

#1 - The discovery workshops don't seem to have a cadence with the project Inceptions

#2 - The team that does discovery workshops is to involved with the project inceptions and vice versa,

Crystal Ball - How you can efficiently manage team productivity

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sat, 07 Oct 2017 16:08:00 +0000

Before I jump into the topic, I will start with some context.

We were working on a very complex product - Complexity in multiple dimensions. As a team, We needed a simple way for us to understand how we manage complexity as team scales and use it as a simple communication tool.

To generalise:

Context:

A complex project
A fairly large team
High Volatility
Product Engineering team

Challenges

A way to manage complexity as a team
Tool for communication on progress
A mechanism to calibrate progress with the bigger roadmap

Crystal Ball

Crystal Ball is a simple tool for visualising progress on a granular scale. It helps in tracking progress and for teams to look at what they can achieve going forward.

It helps in internalising the progress that the team made in the past few weeks and then relate to it as they plan forward.

How we used it

Our team was fairly big - a 7 pair dev team with 3 Was , 1 BA and a PM. We also had an XD and a UI developer.

With a fairly large team, it was important that all of us knew what we were going to do. We had to do it in 2 steps. Crystal Ball was the second step and not the first one.

The first step was to have clarity on the product roadmap. We started that journey by depicting our product roadmap in multiple tranches - with each tranche having a specific business objective.

All our design and architecture decisions were primarily for achieving the objective of that tranche.

Notice - I call that a tranche and not a milestone or a release. There is a reason to it.I will get to that after I cover how we used Crystal Ball.

Once we had focus on a tranche, we were able to come up with a fairly reasonable set of stories for each sprint. Our sprints were one week sprints - pretty brutal but helped us stay focussed and on our toes.

We met for each sprint planning. I had a list of stories and tasks that had to be done for the particular tranche. It was not a complete list. I picked up a subset based on my context and prior conversations with my dev and testing team.

We would go through the list and rearrange the list to understand what can be picked up. The exact set of things that happened when we did the sprint planning with our Crystal Ball is as follows:

#1 - We start with the leave calendar - Each one has to call out their personal holidays . The team called out public holidays and any other disruptions. For example, if people had to take time off for working with other teams like recruitment or had to go for a training or conference, they would call that out.

#2 - We would discuss the roadmap for a specific tranche. We would discuss in detail on what is the business objective, the progress so far, any changes to the overall design or architectural direction.

#3 - We would discuss the crystal ball we had put in for last week. This would give us a view into what we got right and what we did not. We would discuss on why things did not go as per plan ( In essence this was our retrospective)

#4 - We would then attempt to take a stab at the crystal ball for the next sprint. This would involve detailed discussions on each user story and the approach for these stories. At times, we might park stories if they are blocked - either for functional or technical reasons.

How did it help us

With Crystal Ball, it helped us look at details a lot more objectively. We had a week to achieve things. So we had to split them into fine-grained stories and tasks.

We also knew who was not available when. This let to a sense of collective responsibility.

Since the tasks and stories were fine grained, the debates were at a detailed level that all our members were able to contribute - irrespective of their tenure in the project or their overall experience level.

It also helped us list other tasks that we always miss in a typical sprint planning meeting. We talked about fixing tests, performance tasks, analysis tasks, infrastructure tasks, production tasks and anything that would need to be done by this team. There were sprints where we called out tasks like documentation, transition efforts to other team like marketing, user documentation etc.

Answers to some frequently asked questions:

What about team productivity?

Team productivity - measuring and calibrating it - is a myth. You can manage it.

We used Crystal ball as a radiator to let the team know when we as a team had collectively failed to achieve what we had forecasted. This way, we were able to freely ask questions to ourselves on what we could be better at.

The first few sprints were a lot uncomfortable but we quickly got into the spirit of it.

Did you estimate?

Yes we did estimate in story points. However, The story point estimate was only used for getting to our product plan. We did not use our estimate for our crystal ball. In fact, we were estimating for a story or a task twice.

This is a redundant exercise. We did find value in doing this and it helped us a lot.

How long did you do this?

We did it for 69 weeks. That is a pretty long time. We initially had a different structure for the first 2 sprints and then experimented with crystal ball and said with it for 69 more sprints.

What is a Tranche?

Tranche is a point in your product roadmap that you would use to showcase your product. It does not lead to any user touch points or feedback. It does not have any specific monetary value as well. It is to used in terms of securing more funding for the product - that is what we use milestones for .

We use releases - when we want feedback from users.

We used tranches since we had several stakeholders that had different touch points. These were soft touch points that we had to co-ordinate to measure and monitor progress. However, the scale used for progress is ambiguous - it was not features or user journey.

So why did you let your design and architecture be divided into tranches if you had no feedback or user interaction?

We did not start that way. Initially we thought it would be a release. Hence our initial tranche had design decisions local to that tranche.

However, we realised very soon that these tranches had different business purpose. It was for layering functional complexity for the product management team to structure their thoughts.

Hence, as a product engineering team, we learnt to push back on complex product concepts and layer it.

Does it not mean there was rework?

Sure , there was rework. however, we had the benefit of building layers - each one of them tested and hence helped us layering the next level of complexity far more easier to design , develop and test as well.

How does Crystal Ball look?

A Typical Crystal Ball

User Story Mapping - A brief Introduction

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 07 Sep 2017 03:51:00 +0000

User story mapping is a technique that allows you to add a second dimension to your backlog.

The visualization enables you to see the big picture of the Product Backlog.

I references a lot of material from Jeff Patton's website here: http://jpattonassociates.com/the-new-backlog/

Low Fidelity Prototyping - A Brief Introduction

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Fri, 04 Aug 2017 03:23:00 +0000

Proto-typing is the next step after doing your user journeys.

A lot of us put in a lot of effort in port typing.

However, remember that this is not a creative exercise. The goal is to increase the flow of information and reduce uncertainty. Hence the concept of lo-fi prototyping

A lot of the content on this video is from: https://www.smashingmagazine.com/2014/10/the-skeptics-guide-to-low-fidelity-prototyping/

My Weekend Project - Automatic Leave letter generator

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sun, 23 Jul 2017 15:34:00 +0000

I gave a try at an automatic leave leter generator.

Loading...

Features:

PDF of leave letter generated
Emailed to the person automatically
It takes care of a generic set of situations and is generic enough.

Feedback welcome.

User Journey - A Brief Introduction

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Wed, 19 Jul 2017 03:08:00 +0000

User Journey is an activity that we do right after detailing user personas.

It is primarily used for:

Understanding user behaviour
Identify high level functionality
Demonstrate vision of the project

How do you go about creating a user Journey

Your user’s goals
Their motivations
Their current pain points
Their overall character
The main tasks they want to achieve

Courtesy: http://theuxreview.co.uk/user-journeys-beginners-guide/

My Journey in Inquiry and Advocacy - An experience report

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Fri, 14 Jul 2017 14:35:00 +0000

It is recently that I have consciously started practicing Inquiry.

Let me explain. I am a consultant who constantly looks at the situation and comes up and implements the solution to progress from there.

While I do that, I constantly use Inquiry as a means to progress - one of the key facilitation technique specifically in multiple stakeholder situations.

User Personas - Experience Report

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Wed, 12 Jul 2017 16:31:00 +0000

This is a quick experience report on User Personas - Where it has worked well, where I had challenges and why I had those challenges.

User Personas

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Mon, 10 Jul 2017 17:20:00 +0000

User Personas are a very good tool for the product owners, business analysts or product managers to be able to co-create with designers. It is predominantly a product of the user research and should not be an amalgamation of demographic data.

It is the best way for us to list all scenarios that a persona would take when they want to attain a goal.

It is predominantly used to build empathy with user, focus the team and build consensus in a large diverse stakeholder group.

The website I referred to is here: https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/

User Story - A brief Introduction

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 29 Jun 2017 15:48:00 +0000

What is a Retrospective

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 22 Jun 2017 07:32:00 +0000

Introduction to a new Video Series

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Thu, 22 Jun 2017 07:29:00 +0000

Learning in Shared spaces - A Journey

noreply@blogger.com (Prashanth Madhavan Narasimhan) — Sat, 20 May 2017 14:25:00 +0000

This post is a list of my perspective and questions on my journey in shared spaces.

My first experience of learning in shared spaces was back in my MBA days - Where we learn , experiment , fail and reflect as a team. It has been a long time and I got 2 opportunities to do the same in a shared space.

Learning in Shared spaces - A Journey