The 7 Principles of Software Product Management

April 6, 2011
A stool with adjustable height.

Image via Wikipedia

As software product managers, we are constantly analyzing data:  needs from customers, revenue from sales, win/loss reports, development plans and costs, feature specifications, evaluations of competitors, etc.

As we process all of this information, an effective product manager should be guided by 7 key principles, divided into 2 key categories, as follows:

Product Planning

Effective software product planning requires you to balance the following 3 key principles:

  1. Customers — Your customers (or potential customers) represent the needs that your product should be fulfilling and the revenue that your company expects to receive by providing them with a suitable product (or service).
  2. Product (or Service) — This is the mechanism (or method) that your company uses to provide value to your customers.   If your product doesn’t fulfill most of their needs, then they will go elsewhere and buy something else.
  3. Product Team — This is the staff that your company employs (either directly or indirectly) to create and deliver your product (or service).  If your team doesn’t provide a suitable product, your customers will not be satisfied.  And if your team doesn’t know what your customers need, or understand how much your customers appreciate your products, then they will be unlikely (or perhaps, unable) to create a suitable product.

These three principles can be thought of as the 3 legs of a stool, with your company resting on the seat.  As a product manager, you must constantly balance these 3 elements.   If you over-emphasize (or under-emphasize) one of these principles, then your company will fail.   Just like a stool will fall over if one of its legs is overly long or short.

Product Creation

Creating a software product (or service) is an iterative process, whether you are using Waterfall, Agile, or some other development methodology.  In all cases, your product (or service) is provided to your customers in one or more releases.   As a product manager, you must balance 4 additional key principles for each of these releases, as follows:

  1. Content — Each release contains a certain amount of content.  A number of bugs that have been fixed, a number of new features that have been developed, and perhaps one or more changes to the infrastructure of your product.
  2. Resources — Each release is created (and tested) by a specified group of people; usually those who have the knowledge necessary to effectively and efficiently do the work.
  3. Schedule — Each release is delivered (or at least, planned to be delivered) according to a specific schedule, based upon the amount of work that needs to be done and the approximate date when the finished release needs to be completed.
  4. Quality — Each release must achieve a certain level of quality to ensure that it is suitable to used by the desired customers to accomplish its stated purpose.

As a product manager, you must also balance these 4 principles so that each release helps increase the value that your product provides to your customer.

However, in most situations you don’t have nearly as much flexibility.    Each product release must achieve a certain minimal level of quality, and while it is desirable to achieve a much greater quality, it is rare that this happens.   And although it may be tempting to increase the content you can complete within a given timeframe by adding resources — this rarely works — as explained in  The Mythical Man Month.

Thus, you typically have to manage trade-offs between the content that each release includes and the date (or schedule) when it will be available.

Conclusions

Product management is all about balance.   You need to  effectively (and consistently) balance the 4 principles that define the creation of each product release and also balance the 3 principles that govern your product planning.

If you do this well, your customers, company, product, and your team will all benefit — and you will be able to sleep well at night feeling good about yourself — which is always a good thing.


Creating a contract for work done in an Agile environment

March 5, 2011
3 Iterations of Agile Development Framework

Image via Wikipedia

I’ve been talking to some colleagues lately who do consulting work, usually software development, for various companies.  Typically, they have been engaged by clients in traditional (or “waterfall”) projects, where they provided specific functionality that met specific quality criteria and had to be completed according to a specific schedule.   In return, they received an agreed-upon compensation.

These types of projects were relatively easy to estimate, bid, and negotiate with clients because all of the deliverables (content, schedule, and quality) were fixed in advance.

However, as more and more of their clients are wanting to have their projects developed using Agile, their traditional types of software contracts simply don’t work.

One of the fundamental aspects of Agile is that a small amount of the work in the total project is performed in a short time period, or sprint.  Each sprint lasts 2-4 weeks (on average) and the content for each subsequent sprint is identified in part by determining how well (or poorly) the already completed work meets the customers’ needs.  Thus, if a certain bit of functionality is developed in a given sprint, it could be modified significantly (or even re-done completely) in one or more subsequent sprints.

Thus, it is possible for a client to spend so much time refining and “polishing” work that has already been completed, that the overall duration of the project extends far, far beyond the original target completion date.    And as you can appreciate, the client doesn’t typically offer additional compensation to the people doing the work — arguing that the work should have been done “properly” in the first place — although it’s not clear how anyone could have done the work “properly” when the client didn’t know what they wanted in the first place.

It’s clear that the Agile development methodology is not going away — its advantages are too great to ignore.   So we need to modify the contract language we use to engage consultants accordingly.  Otherwise, consultants will either go broke attempting to provide the “free work” required by ever-changing functionality or will simply refuse to perform work in an Agile environment.

Here’s what I think…

In a software project there are only 4 variables — (1) the content being provided, (2) the schedule for the delivery (or deliveries), (3) the quality that is achieved, and (4) the resources that are deployed to do the work.   (Note:  Cost is an attribute of a project, not a variable.)

Thus, if a contract is going to embrace Agile development concepts where (a) the project’s content is allowed to change frequently to accommodate re-work, (2) the project has to achieve a specified level of quality, and (c) the project’s schedule must adjust to accommodate any re-work — the ONLY variable left is “the resources that are deployed to do the work”.    And since every resource contributes a certain amount of effort to the project — the contract must specify a certain amount of work (or “hours”) that the client is paying the consultant (or consulting organization) to perform.

This type of contract is not especially attractive to a consultant because it is too transparent.   A potential client can easily identify the hourly rate for different consultants and compare them with rates from others.  Thus, “premium” consultants (or consulting organizations) must provide additional justification on the “value” of their services — which is often not easy to provide in a convincing manner, especially in difficult economic times.

In some cases, clients are also not as comfortable with this type of contract — because it makes it difficult to justify continuing to do business with a long-established consultant (or consulting organization) when it becomes obvious that their hourly rates are significantly more than those of other potential providers.

However, as more and more contracts are written with Agile development in mind — consultants and their clients will become more comfortable — just as development teams have increasingly embraced Agile in recent years.

So, if you are a consultant I urge you to develop a contract where you get paid on an hourly basis soon, so that you are well positioned to bid opportunities for Agile projects.  And if you are a company that employs consultants for Agile projects, I encourage you to request contracts with hourly labor rates, so that you can optimize the quality of your projects.


Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…


Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.


Managing Requirements — One Approach That Works

October 3, 2010

I’ve had some recent conversations with colleagues and clients about “managing requirements”.  I was surprised at some of the approaches that had been tried — largely unsuccessfully.

And while I don’t claim to have THE answer on this subject, this approach has one significant advantage — it has worked in the past.

Some Background

I believe that “requirements” consist of many different things, including:

  • Issues reported by customers that highlight a need for better capabilities
  • Problems discovered by internal resources that highlight product gaps
  • Market opportunities that identify broad functional capabilities that could be targeted
  • Customer / prospect discussions that contribute specific product needs.  Often this includes “gaps”.
  • Enhancement requests that explain (sometimes in great detail) specific functions where the product needs to be improved

Thus, there is a wide range of specific and broad “requirements” provided by all sorts of internal and external people — and many of the requirements need to be grouped together — either because they logically go together or because without enough critical mass, none of the smaller items could justify the effort to address them.

Lastly, requirements change over time — either because your understanding of what is needed evolves or because the need itself changes.   (For example, if  a requirement specified that your software should support a dual-core processor and a quad-core processor was introduced before the requirement was addressed — you would probably want to update the requirement.)

Required Tools

I believe strongly in using tools for the function they were designed for.  So, I don’t use a hammer to “drive in” a screw — that’s what a screw driver is for.

Thus, I believe that you need the following tools to manage your requirements:

  • Issue Tracker — a tool for collecting, prioritizing, scheduling, and tracking all sorts of issues, including many of the requirement types discussed previously.  My favorite is JIRA, but there are many others just as good.
  • Document Management System — a tool for collecting, tracking, sharing, and managing all sorts of documents.   My favorite is Alfresco, but there are many others.

You may wonder — Why a Document Management System?   Because some requirements require more than a few paragraphs to adequately describe and as previously discussed — requirements may change.  If these “larger requirements” are captured in one or more documents and linked to the issue within the Issue Tracker — you can update the requirements whenever it is necessary without having to update the issue within the Issue Tracker.

My Approach

Here’s the “short” or “cookbook” version…

System Setup

1.  Create issue types (in the Issue Tracker) for the types of information you need to track.  This could include:

  • Bugs
  • Enhancements
  • Product Improvements
  • Major Features
  • Use Cases
  • Stories (and Epics)  — If you’re using Agile.

2.  Add fields to each issue type so that you can capture planning information.  For example:

  • Dev Estimate — how long it would take to implement this issue (or requirement)
  • Dev Estimate Assumptions — any assumptions that were used to estimate the level of effort.  (This is critical unless you plan to re-estimate each task just before you do it, because situations and people change — and you won’t be able to remember the details of each estimate unless the person who made the estimate keeps notes.  And if they are going to keep notes, why not put them in the system?)
  • Dev Estimate Confidence — how confident is the Development organization in this estimate?  “High, Medium, and Low” are often enough, but you may wish to use a percentage.
  • Reference Doc — a field where you put the link to the reference document (within your Document Management System).   You can also create a separate issue type of “Reference Document” so that you can link multiple documents in your Document Management System to the issue — if you commonly need to refer to multiple documents.

3.  Add “planning” capabilities to your Issue Tracker

You need a method to plan which issues (or “requirements”) will be developed next.  If you are using JIRA and Agile, you could use the GreenHopper planning plug-in.  Or you could add a “Target Release” field and pre-populate it with the names of your next 3-4 release vehicles.

The specific tool is unimportant — as long as it is easy enough for you to use, so that you can (and will) use it regularly.

Using the System

1.  Create documents for anything that can’t be described in a couple of short paragraphs or when the description might change over time.

Use your Document Management System to circulate the documents to appropriate internal (and external) stakeholders — so that each requirement is described appropriately.  You don’t want to waste Development time on poorly defined requirements — so spend the time to get them right.

2.  Create issues for each requirement and establish links to their respective documents.

3.  Create higher level “Major Feature” issues

Group related smaller enhancements and improvements under each Major Feature.  JIRA makes this easy with Links.   Other systems offer similar capabilities.

4.  Create individual issues for each customer request

Each time a customer requests a given feature or enhancement, you should record it as an enhancement issue.  And link each customer enhancement issue to an appropriate Major Feature issue.  Thus, when you are evaluating which features to do — you will have a record of the number of customers who requested something, who they are, when they requested it, etc. — which is incredibly valuable.  Imagine your credibility when you contact your favorite customer to ask them if they would like to test a new feature that they specifically requested… (Of course, they will be happier if you are providing their feature sooner than later — but that’s a different issue.)

5.  Plan each release

Plan each release based upon the content that you want to include, the amount of customer interest, and the roll-up of the estimated development effort.

And since YOU decide how frequently you want to launch new releases, you can use this approach for Agile sprints (3-4 weeks) or for major multi-year waterfall releases.

Conclusion

In summary, all requirements (or issues) get recorded in the Issue Tracker system.  All documents belong in the document management system (such as Alfresco).  Documents are written using standard tools (Word, Excel, Powerpoint, etc).  The Issue Tracker becomes your planning tool and you use the workflow and revision control tools of your document management system to manage the distribution, review, revising, and approval of all relevant documents.

I won’t pretend that this is a perfect system — but it DOES work.  And since these types of tools are already being used within a given company — it is MUCH easier to share information with others in the company and to capture data that already exists. Otherwise, you have to convince people to use “yet another system” and duplicate data between your bug tracking and requirements management system — which is simply too much work, invites multiple (and different) definitions of each issue, and makes it far too easy for things to fall through the cracks.

Next time I’ll discuss the benefits of using a Document Management System (such as Alfresco), instead of a source code control system (such as Subversion), to manage documents.

Thanks for reading this far and now it’s your turn…   How do you manage requirements?  How well (or poorly) does your system work?   Is there anything about my approach that needs improvement or concerns you?

Let’s hear what you think…

-dave-


Does Agile work when developing commercial enterprise software?

September 11, 2010

I recently had the opportunity to attend an excellent presentation on Agile / Scrum at the Nashua Scrum Club by Damon Poole, Founder and CTO of AccuRev and Vice President of the Boston-area Agile Bazaar.  The presentation was focused on how true agility requires product development professionals to examine our beliefs.  It was a very interesting, entertaining, and thought-provoking presentation and he is a very engaging speaker.  Highly recommended.

However, as I considered some of the key ideas being discussed — such as rapidly deploying product updates to customers and incorporating near immediate feedback from customers into the planning process for the next sprint — I could not help but wonder how effective these concepts would be when developing commercial enterprise software.

Most of the commercial enterprise software I have been involved with suffer from one key problem — it requires a significant amount of customization before the customer is comfortable deploying it across their organization.

As a result, a typical deployment requires each company to (a) install each new software release in a test environment, (b) apply their customizations, (c) test their customized installation to ensure it does what they need, and (d) deploy the new release in production.   In some cases, this process can take as much as 6-12 months.

As a result, companies in this type of situation cannot provide much rapid feedback on the new release — because the “real users” of the system won’t even see each new release for quite a while.   They also can’t rapidly deploy new releases because the out-of-the-box version doesn’t satisfy their business needs.

Commercial enterprise software is one of the most important (and expensive) type of software for many companies.  And Agile offers too many benefits when developing software  to be ignored by enterprise software providers.

So, how can we (as software development professionals) effectively utilize Agile during the development of enterprise software?

Care to share your ideas, experiences, and/or opinions?


Creating Product Features Instead of Feature Elements — a Key Agile Environment Challenge

July 11, 2010

Ever have one of those situations where multiple events all pointed you in the same direction?   Recently this happened to me on the topic of “feature elements versus product features” in an Agile development environment.

First I had a discussion with a potential client, then a friend was lamenting about incomplete features in his company’s latest sprint, and then there was the presentation by David Hussman on this topic at the July meeting of the Agile Bazaar.   So this is what I learned…

One of the fundamental ideas behind the Agile development methodology is that your development process is divided into small cycles or sprints.  The idea is that each sprint is sufficiently well-defined to allow it to be delivered to your customers.  And then your next sprint could focus on refining previously completed or new capabilities — depending on what the market (and your customers) need.  In this way, your product is theoretically ready to go to market at the conclusion of any sprint, so you don’t have to wait until all of your “planned development” for a given release has been completed (and tested).

However, this approach doesn’t accommodate situations where your product must include a certain set of related features (we’ll call them “feature elements”)  which cannot be completed in a single sprint and which your product really must include.

For example, assume that you are creating a word processing application which will allow users to create, save, edit, format and print documents in a variety of ways.

Your product MUST have the ability to “create a new document”.  Likewise, without the ability to “save” your changes and then “load” or “open” a previously saved document — the value of your product will be minimal.   This is why, most applications that deal with “objects” provide feature elements for performing “CRUD” (Create, Read, Update, Delete) operations.

Yet, some of these feature elements are much more challenging to implement and thus take longer to complete — often requiring multiple sprints — which is at odds with the Agile concept of being able to deliver the results of any sprint to your customers.

A modified Agile approach known as Kanban appears to resolve this conflict, because the focus is on delivering complete product features and not just feature elements.  In essence, a sprint is not suitable for delivery to customers unless all of the key elements of a product feature are completed.   Thus, to return to our word processor example, you might implement “Create”, “Save”, and “Open” in different sprints, but your product would not be distributed to potential customers until all of these product feature elements had been completed.

This development approach seems nearly ideal to me — but few companies seem to be using it and some strong Agile proponents seem extremely reluctant to embrace it.

So what do you think?   Is Kanban simply too new for many people to have tried it?  Or is it better in theory than in practice? Or is it simply not “Agile enough” for you to consider?

Do you have any experience with Kanban or know of any companies that have used it?  If so, what did you (or they) learn?


%d bloggers like this: