Archive for the ‘Product Management’ Category

Weekly Project Tracking in Agile Projects

Tuesday, February 6th, 2007

One of the great virtues of agile methods is that they provide near real-time feedback into the status of the project. At the end of the iteration (or sprint) you know exactly where you stand, and you know which items from your iteration / release backlog have reached the “Done, Done” status of potentially releaseable software. When coupled with velocity and burn-up / burn-down charts, many agile teams think that they everything they need to properly communicate their status to the rest of the organization.Unfortunately, they’re wrong.  While it is certainly important to communicate velocity metrics, burn-up/burn-down charts, and the status of individual backlog items, a well-designed agile status reporting infrastructure communicates several additional and critical pieces of information.

I believe that a status report should serve the following goals.

  1. Publicly and openly communicate the status of the development to the organization in a way that is consistent with Agile practices and helps other groups within the company accomplish their job(s), most notably preparing for the release.
  2. Identify and track dependencies so that the organization manage the overall portfolio of projects.
  3. Identify and track project risks and associated risk mitigation strategies.
  4. Formally track agreements that affect the release.
  5. As needed, track and communicate resource used by the project.     

As you consider these goals, you might reflect that most of them have nothing to do with “agility” and instead have everything to do with sound principles of project management. 

These goals, however useful, mean nothing if the team is unwilling to regularly create and communicate status information. This can be a legitimate point of concern — if you’re spending more than 15 - 30 min a week generating status reports, something is wrong. I’ve long felt that status reports are generated most enthusiastically when:

  • They provide value to the person and/or team creating the report.
  • They are generated relatively easily using the tools that the team is already using to monitor progress.
  • Taken together over the life of the project / history of the release the status reports tell the abbreviated story of the project.  

This means that whatever tool that you’re using to manage and track your project should provide a means to output status information in a simple and straightforward manner. Ideally, this tool is the sole repository of information, so that merely accessing the tool is all that you need to communicate the status of the project.  

Market Maturity and Business Model Choices

Friday, December 15th, 2006

The maturity of your target market is one of the strongest influences on the selection and management of a given business model. In the early phases of a given market, business models should be chosen so that they can be quickly and easily understood, primarily because you may not be certain of the best way to structure them. You may find that your customers prefer an annual license to a subscription, or that they expect discounts if they purchase in bulk. Moreover, despite the best intentions of the business plan, innovators and early adopters may expect and/or demand special terms.

As the market matures, chances are good that your business model will become increasingly complex in order to serve the idiosyncratic needs of different market segments. I helped one client whose growth had stalled attack a new market segment with the same underlying system simply by defining a new business model. The original one consisted of an annual license. The new one was pay per use. The easy part was modifying the underlying architecture so that both models could be supported. The hard part was creating the appropriate price points so that a given customer could choose the best model without harming the relationships with current customers. This is not always the case, however, and it is more typical that changes to the business model can cause significant changes to your underlying architecture. These changes are often so large that they consume an entire release cycle (and sometimes two) to fully implement.

The enforcement of business models also matches the maturity of the target market. In early market stages, enforcement tends to be lax. As the market matures, or in cases where you suspect piracy, the enforcement tightens up. My experience is that product managers and software architects take enforcement far too lightly. You’ve worked hard to create your system, and software piracy is a serious problem. Create a business model that identifies the real value provided to your customers, price it competitively, and enforce it accordingly. Just remember that onerous enforcement will lead to dissatisfaction among honest customers, so be careful.

Choosing a business model is one of the most challenging tasks faced by the product manager, as it incorporates a plethora of factors, such as the business and licensing models offered by competitors (which may constrain you to existing market expectations) and corporate and/or environmental factors beyond your control (such as when another division does poorly and you need to find a way to increase short-term revenue). To help you through the potential morass of choosing a business model, consider these questions.

  • Who is the target market? What do they value? A crisp description of the target market and what it values is the first step in creating an appropriate business licensing model. If you’re not certain of  what it values, consider how it wants to use what you’re offering. Once you’ve determined your market values, show how your solution provides it.
  • What are your objectives relative to this target market? In an emerging market you may wish to capture market share, so create simpler models. In a mature market you may wish to protect market share, so create more complex models to provide flexibility.
  • What is your type of value exchange? In other words, what is basic mechanism that tracks and/or causes “money” to change hands?
  • What rights do you wish to convey? Begin by asking your legal department for a “standard” contract, as it will contain a variety of nonnegotiable rights and restrictions. Many of these you can ignore. Focus on the business terms that motivate sales of your software.
  • What is the affect of this business model on your technical architecture? Work with the software architect to make certain that any business model you propose is appropriately supported.
  • What is the pricing model? The business model provides the framework for defining how you’re going to make money. The pricing model sets the amount the customer will pay. You’ll need to consider such things as volume discounts, sales and/or channel incentives, and so forth. Pricing choices may also affect your software architecture, so make them carefully.

As you develop the answers to these questions, you’re likely to find that the best way to reach a given target market will require a variety of changes to your current business model, licensing model, and software architecture. You’ll have to rank-order the changes in all areas of your product so that you can reach the largest target market. The benefits are worth it, for creating the right business and licensing model for you and your customers is the best way to maximize profits while increasing customer satisfaction.

LinkedIn email Blasts and The Danger and Opportunity of Using Cool Features in Unintended Ways

Wednesday, August 23rd, 2006

A few days ago I received an email from a friend announcing his new job as CTO of a startup company . Except the email didn’t come from my friend. It came from LinkedIn, via a feature that allows LinkedIn users to announce new jobs. Very cool, and very useful. I thought that sending an email announcing the availability of my new book on Innovation Games to my (admittedly small) LinkedIn network would be of interest to my network. So I logged into LinkedIn looking for a way to do this. In the process, I found a great example of how using existing features in unintended ways can both spur creative thinking and run afoul of license agreements. The result provides a lot of food for thought. Perhaps more importantly, the professional manner in which the LinkedIn team handled the situation provides a great example of how to manage potentially volatile situations.

The Goal: Sending a Message to My LinkedIn Network

The first thing I tried was the “Send message:” list of options from the home page (see below). Yeah, I know – this was the completely obvious choice, but let’s give credit to the LinkedIn making it the completely obvious choice.

I must admit that when I first looked at this list I was disappointed, because I didn’t see an obvious way to send an email to my network. Since I’m a freeloader at LinkedIn (aka, “Personal Account”), I started to think that perhaps this was an option reserved for paying customers. This is fair enough, and is certainly a feature that a user might be willing to pay for.

My mind started to wander. I really wanted to send an email to my network, but I imagined that LinkedIn would probably want me to sign up for a monthly fee for something that I wanted to do just once. Time to do a little research. As it turns out, LinkedIn does offer this feature in their various subscription oriented account plans (“Business”, “Business plus”, and “Pro”). The problem is that I don’t write books every month, and I don’t have a lot of reasons to blast emails to my LinkedIn network. As a result, signing up for a monthly fee for a service I’ll use once infrequently didn’t seem like a good choice.

Ideally, what I’d like LinkedIn to provide is a transactional business model for distributing emails (more information on business models can be found in my book Beyond Software Architecture, which I should probably discuss in a future post).

Creative Thinking About a Feature

Back to the drawing board.

My friend had used LinkedIn to send a job notification. This capability appeared to exist for free. What if I were to treat my announcement on the Innovation Games book like a job notification? Innovation Games are, after all, a job that myself and other Innovation Game Certified Facilitators love to do. So what if instead of announcing my book, I was really making an announcement of a new job – Innovation Games.

I selected the menu item “Send job notification” and filled out a form capturing all of the relevant details. It was, again, quite easy to use. I clicked “Send” and voila! A message sent to my LinkedIn network.

The first reply to this email came from Scott Gilbert, President of Enthiosys, who noted that I was misusing a feature. Creatively misusing a feature, but, misusing a feature. He was right, of course, but I thought it was a fun way to get the word out about the book to a network that I thought would want to hear about the same. I didn’t even stop to think that I might have been violating a license agreement. I should have.

SPAM: It is all a Matter of Perception

A few days later I found the following message in my email inbox:

Dear Luke,
We have received complaints that you have used LinkedIn’s job forwarding feature to promote your new book and ask your connections to send the promotion to your connections. Your book looks genuinely interesting. However, I’m sure you’re aware that this is a really blatant misuse of LinkedIn. What you may not understand is how much this actually hurts everyone on LinkedIn by spreading the idea that LinkedIn is a source of spam. That encourages other aggressive marketers to try to imitate this type of misuse of LInkedIn, and it encourages people who end up getting unwelcome spam through LinkedIn to avoid using LinkedIn.
Please read our User Agreement, especially the User Conduct section and let me know if you understand and agree to follow our policies. Until we hear from you we’ve restricted your ability to send messages of any kind through LinkedIn.
Nothing personal here. I hope you understand that we’re trying to keep LinkedIn useful, safe, and non-annoying for everyone.
All the best, and good luck with your book.
Duncan Work
LinkedIn Privacy Officer

I immediately replied with an apology, and Duncan removed the restriction from my account.

It is worthy to examine Duncan’s email in greater detail. It is a superbly professional way of telling me that I had violated my User Agreement. Duncan’s tone is straightforward. It doesn’t make me feel like an idiot or cheater, and it clearly explains why this policy is important to me and everyone using LinkedIn. It opens the door to future conversations, and outlines how to remove my account restrictions.

More importantly, I feel that a person read this email and acted on the situation in a way that was guided by corporate policies and yet tailored to this specific situation. I suspect, but cannot prove, that if I was a known spammer, or if this email was part of a consistent pattern of abuse, that this response would have been markedly different. The unintended effect is that I have an even more positive image of LinkedIn – there are real people there!

I’d like to point out that I’ve tried to manage my LinkedIn network pretty carefully and was therefore genuinely surprised that any member of my network would not be extremely happy to receive this email. Most know I’ve been working on the Innovation Games book for several years, and Innovation Games help you better understand your customers. That said, I must concede that it meets the definition of Spam, and whomever reported to the LinkedIn team certainly had every right to do this.

I’ve learned since then that people are forwarding the message to their LinkedIn network, possibly using the same approach. While I’m happy that the book is being promoted, I certainly don’t want to promote the misuse of LinkedIn features or the proliferation of Spam.

Creative Thinking About a Feature

Recall that this post was motivated by thinking of the Innovation Games book announcement as a new job that I was announcing to my LinkedIn network. More generally, it has me thinking about the power that unintended features have to spur creative thinking and how product teams can capitalize on the same. Right now, I’m wondering what would happen if I were to anthropomorphize Innovation Games and think of them as a person looking for work. What would their resume say? It would probably describe the games, list relevant experience, explain what they’re great at (improving customer understanding) — all of the “normal” things that you put into a resume. Someone reading this resume would then know if they want to “hire” the games to help them better understand their customers. (Hmmm. More creative thinking. That sounds like a data sheet. Maybe resumes are a better format for describing products than data sheets).

What would happen should I post this resume a major job web site? Would I run the risk of unintentionally violating another license agreement? Possibly. And since ignorance of the law is no excuse, I’d be more sensitive to using such resume posting features properly (or at least be more aware of intentionally breaking them ;-).

I am also thinking about how patterns of misuse can be captured and used to promote your products and services. Enthiosys has one client that offers a SaaS solution that has honed their analysis of user behavior to the point where they can identify patterns of misuse in their product and proactively recommend consulting services to resolve problems experienced by the company. These are weighted by the amount of revenue provided by the customer, so that intervention can occur quickly where it makes the most sense. In this example of using LinkedIn, I would have been pleased had Duncan included either of the following in his email:

  1. a link to other service plans that might allow me to accomplish the email goal, or,
  2. a clear statement that there is simply no way to send out this kind of email via LinkedIn.

As I described earlier, another option would be for LinkedIn to offer some of their features via a transactional business model. They’d have to explore this idea very carefully, because I suspect that their financial plans are based on subscribers per month, not individual transactions. As with any business model choice, the trick is matching the value provided to the way that you charge for that value. Keep Media, another Enthiosys client, has found a way to offer both transactional and subscription choices to their core service model with interesting results.

Managing Features For Fun and Profit

One way to think about what product managers do is that they manage features for fun and profit. People like me will use them ways that range from conventional to novel, and in ways that may or may not be compliant with existing license agreements. How do you respond to your users when they creatively use your features? How do you respond when creative use of a feature crosses over the line and becomes a violation of a license agreement? Do either they feed your product innovation engine? If so, how?