When we think of the Product Lifecycle, a common image to grasp is that of the upwards line curve that goes from  Product Introduction, Growth and into Product Maturity and finally on to the decline. In a conventional product  lifecycle, these are indeed the four phases of life of a product.

However, this hardly takes into consideration the real world evolution of a product or business that iterates and pivots to stay competitive. Look at AOL.com — in the early stages it was purely a business to get consumers connected to the internet. Now the product is all about content and very little about getting customers  connected. Sure this is truer with a business, but then core products, within the product lifecycle define the business.

So the point of this as you will see is to provide you a different vision of the product lifecycle. The image below, broken down and explained into individual components, demonstrates the evolving product which always starts with introduction, and might end with an end of life. However, the evolving product can have multiple  stages of maturity, and quite possibly multiple stages of introduction and growth as the product evolves and the  core business pivots.

PRODUCT LIFECYCLE STARTS WITH SOME GENERAL CONCEPTS

It’s so easy to get sucked into the minutia when defining product releases, but DON’T DO IT! STOP WHAT YOU’RE  DOING!! Seriously, you are doing yourself a disservice by jumping into the details before you have laid out what you  want to achieve and the high level concepts. Write down on a napkin or a piece of paper brief objectives, some  ideas for what is important in the next product release (not just the full product).

As you move on down to the bottom right of the product  lifecycle triangle, your goal is to clearly define the product iteration. Getting there involves activities including iteration planning, roadmapping, writing out the business requirements and of course prioritization. Prioritization may be trickier because the critical trade-off is  cost to build versus potential revenue. (Cost-benefit modeling). However you get there, the deliverable should be a clear PRD (product requirements document) with use cases and/or wireframes.

Why do we need this? This PRD is used to communicate between business and technical teams. Do this wrong or  incomplete and the engineering team builds the wrong thing driving up costs. Being able to clearly articulate your requirements up front can mean the difference between success and failure in the lifecycle.

FROM DEFINITION TO A TANGIBLE PRODUCT RELEASE

Now that you have a definition for your product release, relax for a minute and take a breath. Now all you have  to do is engage the engineering team and build it. You can equate this to taking a polished movie script and  turn it into a film. Think how easy it is to ruin a movie with a great script. Your challenge now is taking your  product definition and selling it to the engineering team. Your goal is for them to stay engaged, they can  visualize it and understand why it is you’re building it.

On the way from definition to product release are a slew of activities including overall project management, product design, engineering and wireframing. The most important thing to keep in mind is to keep the iteration  agile and concise so that the time to market is nothing more than 30 to 60 days. If it takes longer than this,  your iteration is getting too big and you may want to prune it down to something where 60% of the features are  in this release. That way you can get meaningful feedback to drive the next product iteration.

As a product manager, you need to be very much engaged at this stage. Be the project manager and keep your eyes  on the development milestones. Have multiple code drops so you can consistently provide feedack so when the  iteration is complete there are little to no surprises.

Also, for every product release you need to make sure there is a feedback loop for your customers. Have a link to a form where customers can provide feedback and report bugs. This will be invaluable information to give you  the feedback you need to drive future iterations. Without this, your ignoring the market and your customers who  you are building this for in the first place.

RELEASE, MEASURE, RINSE, REPEAT

Now that you have a viable/tangible release in market, this is where the fun starts. The biggest mistake you can make is to  sit back and not watch the metrics and stay focused to how your customers (the market) reacts to the release.  It’s this information that will drive the subsequent releases and ultimately your product’s strategy.

Some of the things (if not all of these) that you should now be doing with this release are as follows:
1. If this is a marketing change which will impact customer acquisition, A:B Test the current version to see how  it performs. If it doesn’t perform well, throw it out and start over. Don’t waste time on something that  customers don’t care about.
2. For new features, are customers clicking on it, are they using it, if so, are they asking questions about it.  Is it clear?
3. Consider reaching out to some power customers, offer them a free month to get their feedback on the new  feature.
4. If the new feature is improving revenue, is there any impact on Churn? Nothing worse than getting more money  up front but eroding the life-time value of your customers.

The basic theme of the product lifecycle triangle is “test before invest”. That is, see how the iteration of the produce release  works before investing more of your valuable engineering resources. There is always a massive opportunity cost  at work here.  Invest your revenue back into the product the right way. You do this with smaller releases that  are testable and measurable. If you are building something that takes three months, prior to testing and  measuring, STOP, and reread.

This case study from one of our most prized customers demonstrates how they successfully automated their business requirements process. However, while we were not able to get approval from their legal team to disclose publicize their name with this case study, we are able to make it an anonymous case study and still drive the point home.

Customer Profile

The company is a publicly traded provider of automated retail solutions offering convenient services that make life easier for consumers and drive incremental traffic and revenue for retailers. The company’s core automated retail businesses include coin-counting kiosks and a brand-recognizedself-service DVD rental service. The company has approximately 30,000 DVD kiosks and 18,900 coin-counting kiosks in supermarkets, drug stores, mass merchants, financial institutions, convenience stores, and restaurants.

Situation

As one of two senior business analysts at the company, the Senior Analyst is responsible for defining the business requirements that the company’s internal software development team uses to customize off-the-shelf software, which are critical to the operations of the company. However, managing business requirements in Microsoft Word, Excel, and Sharepoint proved to be a time-consuming and laborious affair as there were multiple versions being circulated simultaneously and no easy way to collaborate with the development team in real-time. In addition, the company’s software development team employed Agile methodologies and needed a requirements management system that would enable them to iterate quickly and adapt to change.

Solution

In early 2010, the senior business analyst grew frustrated upon realizing that she was wasting too much time formatting business requirements documents and trying to figure out an efficient way to share them with the rest of the team. Following a quick Web search, she discovered GatherSpace. Since GatherSpace is available on-demand, offers a 30-day free trial, and is easy-to-use, she was able to register on the site without having to download any software, enabling her to quickly get started. Additionally, because GatherSpace is purpose-built for managing business requirements, it included dozens of features designed specifically for effectively communicating requirements – including visual use-case modeling, a traceability matrix, rich-text editing, and report generation.

Benefits

• GatherSpace facilitates the discussion: The process of producing quality software hinges on the business being able to clearly articulate functional and business requirements to the software team. With GatherSpace, she was able to have a productive conversation with the rest of her team since everyone could see and work on the business requirements in real-time;
• Visualize requirements to ensure quality: To ensure that business analysts are communicating requirements as clearly as possible, GatherSpace provides an intuitive use-case modeling functionality that enables software developers to visualize ‘actors’ and workflows in context specific scenarios;
• Powerful search functionality: Because GatherSpace stores all of the business requirements in a database, she and the rest of her team can search across all of her requirements and instantly retrieve the specific one she’s looking for;
• Anytime, anywhere on-demand access: Since GatherSpace is an online application, the she can access her requirements whenever and wherever they’re online and seamlessly collaborate with others on her team;

Great ideas are meaningless unless they are executed almost perfectly. The Product Managers‘s best shot at success is to deliver their product (or service) the way they see it on their first release.  Using a great product management software tool can be a make or break factor for the success of your product launch by optimizing your chance in delivering the product the way you visioned it.

This blog posting should help guide you, the product manager, to select the best software for this job. There are many software services on the market today and most will position themsleves as a great product management software tool, so if you follow these suggestions, you can make sure you select the best tool. Remember, what’s great for the project manager isn’t necessarily great for the product manager.

So here we go with my top 10 suggestions for selecting the best product management software for the job.

1. Support your project management style. (Agile / Waterfall)
Whether you use Agile or Waterfall for your project management style, you need to make sure your product requirements software supports this. For example, if you are an Agile (or Sprint) shop, you may be working in two sprints/iterations and must be able to pull product requirements from your product backlog, and drop them into an iteration.

If you are a pure waterfall shop, than your project and iteration maybe wrapped up into one monolithic iteration, but you should still be able to define this within the project so that if you need to punt features to a later phase, your software provides the ability to do this.

2. Ability to communicate and socialize your requirements to the cross functional team.
Being “Social” isn’t just a buzzword, it’s an important aspect in the success of your project. It simply means that your cross-functional team will have the ability to easily provide feedback on requirements which then evolve into the correct requirements. Whatever product software you choose, must be able to allow developers or project managers to comment or question a requirement, and have the product manager revise back into the definition.

For those of you (the majority) who use Facebook, you know that when someone comments, you can see a large thread of the comments and can continually track the thread until it eventually dies out. This is the social aspect of requirements management which simulates a discussion.

3. Collaboration is important for soliciting feedback.
As part of #2 above, the collaboration aspect will mean that the product management software should allow users to receive notifications on a change , comment or question, and drive them back into the software to encourage feedback. If it’s too difficult or not seamless for a user to comment or question a requirement, you have just undercut your ability as the product manager to get the best possible requirements in the first pass.

4. Presentation of your reports.
At the end of the day, your deliverables are going to be your requirement reports like your Product Requirements Document, and perhaps traceability reports. The value of your system will be based on how easy it is for your customer or management to consume the report. So if they appear sloppy or unreadable, your system is basically useless. When you are evaluating different Product Requirements systems, don’t be shy about asking the vendor to send you some sample reports. If you find them difficult to read or generate, you found your answer.

5. Stakeholder approvals of requirements.
The customer who is paying you to build your system may only need to view reports, or just be the approver of requirements. For this reason, good product management software will provide an Approval only capability where the stakeholders can log in and approve requirements. Performing this task should be very simple, and done without or minimal training.

6. Less is more (simplicity)
For those of you who have read any of my material or blog posts, you are probably so bored of me talking about the 80/20 rule. Too bad! ..because it’s such an awesome rule that can be applied to making so many aspects of our lives more efficient and simple. In this context, we have seen so many of these Product Requirements Management tools get so bloated and complex. This happens when the management of these vendors want to please everybody. The best product management software can be used without a training manual, and will appear to be simple to use even with strong offerings. You want to choose a tool that accomplishes 80% of what you’re looking for. Go for a simple tool and you will be amazed at what you can accomplish with it.

7. Integration with Word/Excel
While Product Management Software vendors attempt to push their customers into using a web (or desktop) interface to manage their requirements, the truth is that most product managers and business analysts prefer to use Word or Excel as their database to manage their requirements. The enormous bulk of these customers will never move to a tool. So the best thing you can do when selecting such a tool, is to find one that allows an integration between Word and the tool. A product manager could then still use Word to publish and manage their requirements, and push the data into the datbase with one fell swoop.

8. Working in the Cloud
Some of the best tools on the market are Cloud based (SaaS) tools, and that’s where our market is heading so given the climate of global resources and disparate teams, it wouldn’t make sense to not use a cloud solution to manage your requirements. As a critical criteria for selecting a Cloud based tool is to make sure they have world-class data security. That means securing the privacy, and security of your data. I could probably provide a separate blog post on selecting the best Cloud based tool, but the security and privacy of your data is critical.

9. True Open System (integration with jira, etc.)
Whether you are using a Cloud based or desktop tool, this system must be able to open it’s doors to receiving or sending data. At some point you will be needing to integrate into a bug database, or a task management system, or something that needs to interface with your product requirements. Having a “closed” product management system (one that can’t interface) will cost you down the road. At the minimum, the tool should be able to provide a simple import and export mechanism. The better ones on the market will provide you hooks or customer API’s for publishing or receiving data.

10. Offline Capabilities
I hate the thought of a product manager hobbled from writing up requirements, just because they’re not connected to the internet. Sounds pretty lame, doesn’t it? That leads me to #10 — a product manager tool should be able to allow the product owner or analyst to write up requirements when offline. This is more of a tall order for SaaS tools, but not impossible. There are many ways for vendors to provide an integration from MS-Word so that you can queue up your requirements while offline, and have them imported once you’re get connected.

While there are other things I could have put on this list, these suggestions should be a really good start for your evaluation process.

We ended 2012 with mentions in a Technorati article discussing the future of Cloud. Gatherspace in the same breath as Google — ahh, maybe a stretch, but we’ll take it!!!

“Software is a trillion dollar annual industry and will continue to thrive in many facets of life from medical billing to gaming and everything in between.  With Microsoft seamlessly keeping cloud applications at the forefront of their Office software modeling, Google is attempting to keep pace with Microsoft’s surging future yet recent CNET coverage of this ongoing battle dictates Microsoft isn’t worried about anything Google develops.  While proverbial software kids fight over their toys, one company crawling ahead of both when speaking of project management software on the cloud is Gatherspace.”

For the full article, please click the link below.

http://technorati.com/business/small-business/article/microsoft-google-gatherspace-tee-off-on/

The practice of AB testing has been so common among the product management community, that most mid level product managers understand the basic concepts and know how to put it in practice. Yet, when pressed about how to push AB testing to the limits and how to really move the needle of the business, most product managers fall flat on their face. This is why it can be very dangerous for a company to have an optimizer looking at the wrong metrics, thus making careless decisions.

As someone who has been doing this for several years, I have made mistakes and watched others make the same mistake. So below are what I consider the top 5 critical mistakes when AB testing.

1. Not AB testing the application

You would be surprised to hear that most AB testing happens at the top of the funnel. Obvious AB testing candidates are home pages, landing pages, and product pages — these are really good things to test, but testing shouldn’t end there. You want test every possible funnel candidate from the top of funnel down through the bowels of your application where customers are performing critical activation and engagement activities. If a customer isn’t activating or engaged, chances are they’re not paying , so why not AB test these experiences?

2. Watching conversion, but not RPV (revenue per visitor)

AB testing is not all about conversion. A basic conversion metrics (visitors/traffic) is great in testing certain creatives on a homepage and a registration event, but useless when testing through the purchase process. Especially when testing the introduction of new products and pricing, you may in fact increase conversion but lower your revenue per visitor (RPV). Such an obvious point is when you lower the price, you can increase your volume but not sell enough to make up the difference. This is where following the RPV metric is critical in AB testing.

3. Not paying attention to Life-Time Value

Other than not watching revenue per visitor (RPV), often customers will watch this metric but fail to measure the long-term value (LTV) impact of a change and follow the ARPU (average revenue per user). For example, let’s say you raise your prices by 20% and the 24 hour revenue goes up, but because the monthly cost is too high, customers churn out too soon. While your RPV appears higher, your ARPU goes down. Customers must be able to watch this metric as well.

4. Not allowing the test to run long enough

This is a fun one, and is very common. After watching an AB test after a day, a product manager or marketer can see that the test is winning (or losing) after a day and turning off the test or making it 100%. The truth is, you need to see at least 1 to 2 weekly cycles to see how customer behavior changes intra-week. Most AB test tools will allow you to follow the metrics on a daily basis to see if one experience has a consistent winning or losing effect. Declaring a decision too soon, could mean disastrous effects on revenue over time.

5. Not properly segmenting customers

Segmenting your AB tests is such a key way to learn about differences customers buying patterns. What may work for a female, may not work for a male. What works for someone older than 50, might not work for someone in their 20′s. Buy watching how an AB test performs on various customer and technical segments, you may and should end up with different experiences for different customers.

For example, your AB test experience could lose by 5%. But what might be happening is that it’s winning by 20% for people on the east coast, but losing by 25% for people on the west coast. By understanding the segments, and then targeting the right experience for the right audience you’ll end up ahead overall.

This  post was about to be titled “Why Business Requirements are going to be obsolete” but that became secondary to the value of prototyping.  Writing detailed functional business requirements are almost a thing of the past, and you will see why low fidelity prototypes are replacing them as the vehicle for delivering lean and rapid throw-away software.

So what are low fidelity prototypes anyway?

There’s nothing more demoralizing to a product team then sweating out a product for months only to see it discarded within seconds. Thanks to Agile and the lean UX movement, product releases are intended to cycle through waste and optimize value without having to invest months on product development.  While medium to high fidelity prototypes are 80% functional and resemble the Alpha, low fidelity prototypes are crude, grey scale mockups that are clickable, yet still feel like a functional product.

Apple’s ANPP (Apple New Product Process) always starts with design and is meant for creating and testing hundreds of releases.  Every one of their products starts with design, without anything written. The basis for this is that investing design and development hours without stakeholders involvement, is wasteful, makes no economic sense, nor does it effectively guide the product towards success.

From requirements-centric to prototyping as a way of getting buy-in.

I recently accepted a 6 month contract at a Fortune 100 London based company, with the task of conveying how fund managers can sell millions of pounds of mutual funds using nothing more than an iPhone app. I had to rapidly interview and collect all requirements and build something they would accept in less than 90 days.  Their last vendor failed because they delivered a binder of requirements that were not read, nor understood.

Knowing enough about Photoshop to be dangerous, and coupling that with thoughtful UX principles and a prototype creation tool, I cobbled together a functioning clickable iPhone app to get into their hands.  While they didn’t love it at first, I was able to get an incredible amount of feedback putting me in a position to deliver a quick iteration that allowed the business stakeholders to buy-in and rally around.

Written functional business requirements are often very ineffective.

Anyone involved with the development of an app, back-end software, or any kind of start-up knows that building products are done in a traditional linear pattern — conceptualization, definition, and development.  Whether you’re building an Android app or an accounting system, you’ve probably experienced the pain and anguish in writing requirements or reading them. Yes, they are that bad but the good news is they’ve almost completely gone obsolete, in favor of functional prototypes.

Before I get into the reasons why prototypes are so effective,  let’s look at the shortcomings of business requirements, (also knows as requirements documents).

As a long-time product guy and software engineer with a “4″ in front of my age, I’ve written more requirements documents than I care to think about. It’s just the way it worked. It was a hand-off artifact, a milestone deliverable which is to produce often binders of written requirements. There are even dozens of requirement apps just to help write them.  Dev shops and larger companies are still writing them because they’ve accepted failure as a typical outcome of development. Over 45% of products fail because of customer rejection, or non adoption.

Let me give you a few key reasons why written requirements will never survive on their own, especially when trying to socialize and attain buy-in.

#1. Business requirements documents take too long to write.  Even with over 58% of development going Agile, writing a requirements document and getting buy-in can take months. Not just in writing time, but the time it takes to get your audience to read them, comment on them, and iterate. The market or the business needs change in parallel and what has been written becomes out of date.

#2. Misunderstanding leads to building the wrong product.  Perception of requirements become everything when you’re dealing with translating the written word into a visual, tangible thing. Try and write a document what the Mona Lisa looks like. In my own experience, I’ve seen accepted requirements docs turn into something that wasn’t asked for. The cost of building a wrong product can go into the millions depending on size, and almost guaranteed will result in failure.

#3. Stakeholders will flat out refuse to read them, and simply wait for the finished product.  Nobody is going to disagree that executives (who are usually the stakeholders) are short on time, I dare to say short attention spans, and usually won’t agree to read through a requirements document for hours. If you’re sharing an elevator with the CEO of your company and you have 90 seconds to convey and explain what you’re working on, would you rather say, “Hey Dave, let me show you this 200 page document explaining the new auto buying app.” or “Hey Dave, check out this app I’ve been working on.”

So why are low fidelity prototypes so successful?

1. It’s now an expectation by the customer. Executives and stakeholders are cozying up to rapid and lean product delivery, so they expect to have something to “play with” almost immediately.  Not having a demo or a prototype to won’t help your cause in getting buy-in. Even if there are a few broken links or bugs, they will get over it knowing it’s a low fidelity prototype. Any feedback is good feedback. Once you keep iterating, they’ll soon forget about the buggy older version.

2. A picture’s worth 1,000 words.  If a picture is worth 1,000 words, a functioning prototype with behavior, latency and functionality, is worth 1m words. Something that can elicit feedback and emotion, whether bad or good, is so important in aligning a stakeholders perception with the delivery of the provider.

3. The availability of prototyping software.   With the onslaught of online and offline prototyping tools available, and in some instances completely free, there’s no excuse to not providing a prototype. I personally learned how to use Invision and had a prototype within 48 hours of signing up for an account. (Full disclosure, I have no connections with this company)

4. Flipping on the light bulb.  There’s nothing better than that “oh sh%t” moment. I was recently demonstrating an iPhone app to a group of fund managers and one of them was so engaged, he was embarrassed because he didn’t know if the prototype was a real app. He just flat out proclaimed, “i want this, when can I download this?”. Not to mention it’s an amazing feeling to know you’re providing value, but it gives the product more momentum and spirit.

5. People now have shorter attention spans than goldfish.
In a recent study by the Canadian media consumption, human attention spans have dropped from 12 seconds to 8 seconds, now lower than goldfish.  In our world of twitter feeds and emoticons, we read less and want more quicker. Add to that, executives are hyper focused on margins and eliminating waste. With the precious commodity of time, don’t even think of expecting an executive to read your 200 page binder of requirements. Hand them your smartphone with the app and you’ll have more luck.

To sum this all up, while many of you are shaking your heads with the notion of replacing requirements with a prototype, consider this.  When your customer or the person who’s writing the check gets it and is onboard, it’s not just the greenlight for the product, but your selling yourself, and promoting your brand as someone who can understand, convey and ultimately deliver a product to the next level.

We started Monday morning with a great mention in Dr. Dobbs  article called “Requirements Management With Prioritization” by Adrian Bridgewater.

“To its credit the company has also pointed out that as a hosted cloud application, GatherSpace enables anywhere, anytime access to development-related data so that distributed teams can collaborate on requirements in real-time. This hosted element may indeed be GatherSpace’s most important ace card. With so many application development scenarios still based on requirements management taken “by hand” (i.e. using basic productivity applications such as Microsoft Word/Excel), there is still a need (for many) to bring requirements management and version control into the 21st century.”

For the full article, please click here and enjoy.

http://drdobbs.com/web-development/231602097