Vision-Passion-Communication=Successful Product Management

Without wasting any word here are my top 5 tips for successful product management–

Understand the Vision, become one with it

How will it help – Ask any product manager how many feature request he or she receives on a weekly basis. If you find that any feature request is not in alignment with the vision you can easily deprioritize it. Having the vision in your DNA will also help you in coming up with ideas and solutions to problems which the market may not have encountered.

Spend at least 30% of your time talking to customers

How will it help– No product is any good if it has no takers. Your customers can be your best critic. Many a times you as a product manager may overlook the uselessness of some existing feature or the need of an essential feature, which a customer can tell you about. I always feel the need of Product Managers interacting directly with customers rather than going through sales or account teams. Many a times the sales people come with an immediate problem as well as an immediate suggested solution, completely missing valuable information pointing towards probably larger problems that the customer might face in the near future. Your solution might be impacted if beforehand knowledge about the problem in greater detail is there.

Create a shared understanding with the Development Teams

How will it help– Imagine someone tells you to go in the forest and get him a piece of wood measuring 4”x 5”. What would you do? You will get the first piece of wood meeting the specifications. Now imagine the same person tell you to go in the forest and get him a piece of wood –preferably mahogany or teak which will be used to sculpt out a figure of an Egyptian Goddess and will be shipped to the Egyptian Museum as a collection in the International Section. What would be your reaction? You would go in the forest and try to find out the best piece of wood available. This is the power and magic of shared understanding. When all stakeholders know what is being done , why it is being done and what are the future implications and value offered the results are awesome.

Create a balanced backlog

How will it help – Always remember that as a product manager you are responsible for the ultimate success or failure of the product. To achieve success the product must address the business problems, should be high in quality and should have the least time to market. To do all these the product backlog must have stories to address the following-
(a) Feature Requests
(b) Technical Debt / Defect removal
(c) Architectural bedwork to address the future needs

Don’t keep singing the MVP Song

How will it help– In the recent times a lot has been written about MVPs and how beneficial they are. But with experience I have learned that MVPs are good only when your product is in a new market without any competition , offering unique services . Whenever people have the option to choose from a multitude of products your MVP will probably not work. In that case you need to launch products which will stand out from the competition’s offering. So don’t be too obsessed with MVPs but do a thorough competition analysis and an analysis of the problems your product is trying to solve . If you think that your release is solving some critical problems and users have no alternatives only then go with MVP releases, else releasing MVPs all the time will do more harm to your brand than good.

In the previous article (https://agileproductleadership.wordpress.com/2015/04/17/is-the-scaled-agile-framework-safe-really-agile/) we discussed about the areas in which SAFe fails in helping an enterprise become Agile. In this article I will propose a model which may help enterprises become Agile. I call the model as Collaborative and Linear Agility Nexus (CLAN). The purpose of CLAN is to uphold the spirit of agility and imbibe the same in an enterprise. Before I go into the details of it let us take a look at the goals it is trying to accomplish –

Responding to change to ensure responsiveness to market/customer needs

Now, let us take a look at how a CLAN looks like-

Above figure shows how a CLAN for product X looks like. This is a representation of a CLAN responsible for a Product or a module within a product. It represents the roles which are responsible for the conception, launch, sales, growth and evolution of the product. The Top Bar is the CLAN leadership which comprises of specific roles with well-defined responsibilities. The roles are not necessarily an individual but there could be multiple persons in one role, like multiple Product Owners or Technical Architects. The main responsibility of these CLAN members would be to ensure the product is a technical and a commercial success. The roles are just suggestive, depending on the roles defined in your organization you may create a CLAN like this which ensures it is linear and collaborative. The Dev Teams will work with the Product Owner, Scrum Master, Technical Architect and Program Manager to deliver working software in cyclic iterations.

Some of the prime responsibilities for each of the roles would be-

Product Owner (Vision | Roadmap | Revenue)

Collaborate with Marketing, Sales and Customers to understand the problems that needs to be solved

Collaborate with Technical Architect(s) to formulate solutions that meet Business and Technical Goals

Collaborate with Development Teams to create a shared understanding of the vison, roadmap and features that need to be built to ensure the growth and effectiveness of the product

Scrum Master (Coaching | Timely Delivery |Impediment Management)

Collaborate with the Development Team to ensure timely delivery of working software

Collaborate with the Program Manager to ensure impediments are resolved and in control

Collaborate with the Development Team and Coach them to ensure they have sufficient working knowledge of Agile/Scrum

Technical Architect (Architecture | Technical Delivery | Innovation)

Collaborate with the Product Owner to ensure a suitable architecture is designed for the product

Collaborate with the Development team to ensure a shared understanding of the Architecture

Collaborate with Marketing Manager to gain information in industry trends and help the Product Owner to deliver solutions better than the competition

Development Team(Working Software | Quality | Reliability)

Collaborate with the Product Owner and Technical Architect in understanding and implementing high quality Product features as per design and business requirements

Collaborate with the Scrum Master in ensuring high reliability

Collaborate across development teams of the same product to take care of dependencies during planning, implementation and delivery

A couple of questions may arise in your mind –

What happens when there are multiple products or product modules within a large scale enterprise product?

How do Dev Teams communicate and collaborate with each other

To solve the first question we may connect individual CLANS to create a bigger CLAN, which may look like this.

This will ensure each CLAN is responsible for their own Product Module and also collaborate with other CLANs to remove any dependency related issues. So the Product Owners, Program Managers, Technical Architects etc. of multiple CLANs may communicate and collaborate with each other to ensure the overall success of the product. This linear inter and intra CLAN ownership will ensure maximum agility, entrepreneurship, customer collaboration and responsiveness across an enterprise; which in turn will ensure success both in the short and long term.

The answer to the 2nd question is simple- The dev teams of a CLAN need to communicate and collaborate amongst themselves to ensure timely delivery of software. The Scrum Master, Product Owner and Technical Architect may initiate or facilitate this communication and collaboration.

Do you think this model can be implemented in your organization to attain increased agility and responsiveness?

When I was looking for a more challenging assignment last year and had appeared for some interviews for the role of Agile Product Manager, the one question which was being asked on multiple occasions-

How will you increase the velocity of the development team?

What really surprised me was, how can someone conversant with the agile methodologies think of such an irrelevant question?

Why did I think it was an irrelevant question?

Here’s the answer-

What is Velocity of a Development Team?

Velocity is the sum of the effort in story points that a development team delivers in an iteration/sprint. To arrive at that, the development team has a Definition of Story Point, which is essentially a sample story which should be considered as 1 story point. Then based on the complexity of the actual stories to be worked on, the Dev Team estimates them based on relative complexity. As an example, if making a cup of tea is 1 story point, then making porridge could be 5 story points. Once all the stories are estimated in story points, then at the end of the sprint depending on how many stories the team successfully completes according to Definition of Done (DoD)(A list of tasks that needs to be completed for a story to be considered DONE) the Velocity for that sprint is calculated. So, if a team delivers 10 stories of 3 story points each, then the velocity for that sprint is 30 story points.

What are the dependencies for determining the Velocity?

There are two prominent dependencies –

Definition of Story Point

Definition of Done

What does it imply?

A Development team can easily double their velocity either by changing the definition of story point or by changing the definition of done. If, the development team decides that from now on 1 story point will mean-preparing hot water for tea, then making tea itself will become a 3 story points effort.

Similarly, if the team along with the product owner removes a couple of tasks from their DoD, they can easily deliver more story points per Sprint.

So, increasing the velocity is a trivial thing for a smart team.

But, is it helping the business or the team?

Definitely not.

But, if you ask to keep these two dependencies a constant then the only way to increase the velocity would be to give more time to the team so that each team member becomes more comfortable working with each other, knows each other’s strengths and weaknesses and is more conversant with the details of the software architecture.

Q: What would have been a smarter question?

Ans: How to increase the business value delivery?

At the end of the day, the velocity is a metric for the team and the business shouldn’t really bother about that. And increasing velocity doesn’t necessarily mean increasing business. What we need is a continuous effort in increasing the total business value delivered each sprint/release.

Most IT organizations around the world have realized the effectiveness of Agile Software Development. An Agile Development team delivers working software at frequent intervals of iterations, which not only increases customer confidence, but it also reduces risk and increases business value considerably. But is agility only to be considered for development teams? Definitely not. Being Agile needs a huge change in the mindset of the entire organization. In a small organization where business and IT work very closely it might not be such a challenge for the business leadership and stakeholders to create a homogeneous Agile Structure within the organization, but for larger organizations where the business is often cut off from the IT, if agility is left only to IT then it will be an assured failure, because agility cannot be limited to the development teams, whereas the business follows an age old hierarchical structure. So what is the way around?

Dean Leffingwell came out with a very interesting model for enterprises who wants to practice enterprise wide agility; it is called the Scaled Agile Framework (SAFe). It looks like this-

In this framework you have essentially 3 levels- Portfolio, Program and Team. The Portfolio level decides on the Strategic themes that should be worked on , creates Portfolio Epics out of them and assigns them to the Program. At the Program Level the Epics of the Portfolio are further refined and broken down into features which are then assigned to teams to be delivered in Iterations spanning a Release Train. The framework looks really nice and seems to be quite promising in terms of creating a homogeneous agile organization. But is the framework really Agile? Will it actually help an enterprise become Agile?

To answer these questions let us take a look at the Agile Manifesto-

Now if we compare this to the SAFe framework, we may get some answers.

Individuals and Interactions over Process and Tools

The SAFe is mostly about defining a process and workflow for delivering software. A portfolio first decides what needs to be done, then it is assigned to a program, which then assigns it to a team. So the team, the Product Owner, the Scrum master, the Technical Architects are really just a “pawn” in the process and there is hardly any interaction or feedback happening in assignment of work. SAFe fails.

Working Software over comprehensive documentation

After implementing SAFe organizations are still delivering successful software at each sprint/release. SAFe wins.

Customer Collaboration over Contract Negotiation

In SAFe I really don’t see a way where in you can involve customers in Sprint Reviews or Release Reviews. Maybe you can, but it is not really evident from the framework. Let us consider we can collaborate with Customers at the end of every sprint. SAFe wins.

Responding to change over following a plan

This one is a little tricky, because if you see SAFe, the Program is planning Agile Release Train which comprises of multiple sprints/iterations and whatever has been planned in the release train is being worked on by the development teams. If there is some feedback given by customers at the end of the sprint , then first the changes have to be captured at the Program level, then it has to be communicated at the team level, the same also needs to be updated at the portfolio level. I see this thing getting quite messy. So honestly, I don’t see much scope of responding to change in SAFe. SAFe fails.

So as we can see SAFe is failing on two points and winning on two points; now the call is absolutely yours whether you want to use SAFe or create your own Enterprise wide Agility model. If I were you I would have created my own Agile Enterprise Framework fulfilling the Agile Manifesto.

In my next article I will propose a plan for the same. Please wait till then.

Sun Tzu, the great Chinese Military General and Strategist wrote ‘The Art of War’ more than 2500 years ago; but it holds true even today and the principles mentioned can also be applied to other fields. It is not something new to us that ‘The Art of War’ has been used extensively around the world as a study to understand and learn about leadership. But is there a way ‘The Art of War’ can help us in understanding and defining product strategies and road-maps in this fast paced and ever-changing technological landscape? I think we can surely learn a lot from it and even apply some of the principles for creating winning products. Here I have listed five of them, you may deduce more from the book.

So in war, the way is to avoid what is strong, and strike at what is weak

When coming out with product ideas and road-maps in an existing market where you already have a competition, it is a more prudent and wise move to create a product that “fills in” the voids left by the competition, which is a weakness of the competition. Most often than not companies try to create products which are a better implementation of existing solutions offered by the competition. By doing so we are striking the enemy’s strength and not his weakness. The chances of failure are very high in this case.

Who wishes to fight must first count the cost

We know the saying-“There’s no free lunch”; but often we forget it. When we are trying to create a product that will literally “mow down” the competition, we need to account for the costs involved in that. I have seen a tendency to overlook this aspect in many startups. You can’t take on a $20 million competition with a $500,000 investment from your part. There is a short term cost as well as a long term cost involved in any product roll out and as an entrepreneur or product manager one needs to diligently do these calculations and tune their ROI expectations accordingly. But this point is closely coupled with the first point, the cost will come down if you implement point 1 really well.

To know your Enemy, you must become your Enemy

The current scenario in the IT product domain is nothing less than a battlefield with fierce competition in terms of technological innovations, new ventures, and merger and acquisitions. To survive such a war and defeat your enemy you need to think like your enemy. Many a times when we are building some new product we tend to overestimate its benefits and we think this is the coolest thing ever. But, if we become our own critic, if we become our own competition we can easily find an answer to these questions-

How cool is the product

Do we have something better than this

Can we “kill” this product with our capabilities and future roadmap

This may really help us in estimating the actual benefits of the product, the future roadmap, and the price that we should charge.

Opportunities multiply as they are seized

If we consider the first point about striking the enemy’s weakness, then as a modern day product manager one really needs to seize individual opportunities within a landscape of multiple problems. Once you gain customer confidence then go on building more features to win over other opportunities. The most evident solution is creating MVPs to “fill-in the voids”. Once you have satisfied customers then go on enhancing the MVP, and multiply your opportunities.

Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win

Once during a product roadmap meeting I remember one product manager had asked the product portfolio manager-“What is the guarantee that these features will be a success?” to this the Portfolio manager had replied-“There’s no guarantee”. Imagine a commander in war giving the same reply, well God save such a country. This point essentially means unless you have a winning strategy you can never win as a product, no matter how efficient your tactics may be. To create a winning strategy is not easy. This point is the deal breaker for any product manager, this will differentiate you as a winning product manager from the rest of the crowd. But how to “Win- First”? If you follow the 4 points mentioned above you are already half-way through, the remaining half will depend on your own skills and intuition as an entrepreneur and product manager.

The Kargil War was an armed conflict between India and Pakistan that took place between May and July 1999 in the Kargil district of Kashmir and elsewhere along the Line of Control (LOC). The war is considered as a classic case study on mountain warfare and how India achieved the near impossible feat of capturing the peaks from the enemy. In mountain warfare it is a common knowledge that when you are attacking from a lower altitude to higher altitude the chance of victory is miniscule.

So how did India really achieve it?

The Answer- By Being Agile.

Let’s take a look at the three lessons every Agile Software Development team can learn from it-

Small teams are the secret to success

In the Kargil conflict when all means failed and India suffered heavy casualties, then they created very small teams who carried out Cliff Assaults – Climbing from the steep side of a cliff in very small coordinated teams to maintain surprise and stealth and then taking the enemy by surprise on reaching the top. In many organizations it is a common practice to have very large teams, as big as 30 or 40. This is absolutely wrong. You can’t be effective as an Agile Team with more than 10 members. Ideally the team strength should be 3-9. This will ensure better communication, collaboration, cross functionality and overall effectiveness as a team

Determine mission feasibility early in planning stages

While carrying out the cliff assaults there were some general considerations which were carried out really well-

Realistic Planning in what can be accomplished

Equipment requirements and the assault force capabilities

Aerial reconnaissance of the area

This effectively meant that the teams knew what was to be achieved and whether they had the capabilities to achieve it.

In some Agile Teams it is a general tendency to blame the planning in case of a failure. They tend to forget that it is, their responsibility to achieve the goals and to do so they should have a “mission feasibility” plan session, if some information is missing or is required, they should ask for it. Without a proper goal setting and feasibility planning it is not wise to go ahead with a sprint execution. The Role of Backlog refinement along with the Product Owner also plays a crucial role in this; it lets the team know what needs to be done and whether they are “well equipped” to get the job done. It is also a primary responsibility of the scrum master to anticipate and foresee if there could be any impediment in terms of infrastructure, licenses etc. to achieve the sprint goals and bring it to the notice of the Product Owner and the Development Team.

Beware of Losing focus on the end state

A cliff assault is a thoroughly planned action on a known danger area. The unit’s mission is the raid beyond the cliff, not climbing the cliff itself. Since climbing the cliff involves a lot of effort and skill it is a natural tendency to reach a relaxed state of mind on nearing the peak; but the Indian Army didn’t relax, they had the focus on the end state. Similarly many Agile teams do the mistake of focusing on tasks in a user story and on completion of the tasks itself they get into a relaxed state of mind, forgetting that their final goal is to deliver all the stories in the sprint as per definition of done. The focus of an Agile team should always be in delivering stories as per DoD and not the completion of tasks only. A story board to keep track on the progress of stories might help in this case.

There are other lessons to learn as well, like- Distributed Team co-ordination, Time management and many more; studying the operation itself will give you more insights.