Part I: What is a Product Lifecycle Process?

Part I in a 5-part series about the process of implementing a new product lifecycle process within a high technology company.

A Great Product Life Cycle Process is the Framework of a Great Company

If you work in high tech, then chances are you follow some sort of product life cycle process — it’s the structure imposed on the development of a software product from the moment the idea materializes until the product must be retired. The question is: how good is the product life cycle process that your company uses? Should you optimize your product life cycle process to be more effective?

  • Do your company’s departments all work in silos, handing off work via Project Managers?
  • Do cross-departmental deliverables arrive late, incorrect, or insufficient?
  • Is company awareness of what major projects are being worked on very low?
  • Do your products or features have a tendency to fail in the market?
  • Is there little to no project transparency for major projects?
  • Is there a lack of individual accountability?
  • Do you often have to complete tasks that are not part of your job description?
  • Does your company suffer from project bottlenecks?
  • Are critical or late-stage resources constantly stressed and overworked due to receiving dependency materials too late?
  • Is your product bloated with features guided by the HIPPO (HIghest Paid Person’s Opinion) in the room?
  • Do products get released and then get abandoned?
  • Do projects get going and forget to include the right people until it’s too late?
  • Do you find yourself with questions about the project and not knowing who to ask?
  • Does your company seem to have arbitrary release dates and budgetary planning?

If you answered ‘Yes’ to any of those questions, it sounds like your product lifecycle could use an update.

What is a Product Life Cycle Process?

A product life cycle’s (or PLC for short) main goal is to ensure that the right people are working on the right projects at the right time. It identifies what tasks need to be completed in order to bring a product to market, as well as who is accountable for each task, who is responsible for approving each task/deliverable, at what point in the cycle each tasks needs to be completed, and so on. You can think of each product as having a point of conception (defining the idea of the product), then moving through an elaboration period (defining the specifics of the product) before going through the actual construction of the product (development), and then being released. And it doesn’t end there — a good product life cycle also accounts for the maintenance of that product (refining and adding additional features), measuring its success or failure, and eventually determining an “end of life” plan for it when it becomes technologically unsustainable, or irrelevant to the market or business.

While there are a plethora of process styles to choose from (each with their own varied approaches and timelines to essentially the same set of tasks or activities that need to take place), the two basic frameworks are Waterfall and Iterative (most commonly referred to as “Agile”).

Waterfall Product Lifecycle Process

Requirements > Design > Implementation > Quality Assurance > Maintenance

An illustration of the Waterfall model (source: http://blog.hydro4ge.com/waterfall-to-boehm/)

According to Wikipedia, “the waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.” I couldn’t have said it better myself :). Basically, the Waterfall model’s aim is to plan a product 100% before handing over a “how to” guide of fully completed functional specifications to Development to build it. The spirit of this concept is to crystalize each team member’s efforts within a phase — the Business folk huddle up from Conception to Analysis, then hand it over to the Design team who create the mockups per their requirements, then they hand everything over the fence to Development for Construction, Testing, and Implementation. Waterfall models generally work best for cultures that demand order and structure.

Pros and Cons of Waterfall Model

Pros:

  • Predictive model front-loads risk to planning phases
  • Departments stay focused on specific tasks
  • Emphasis on planning and research
  • Staged approach enforces discipline
  • Roles + tasks are well-defined
  • Progress is easy to define through Waterfall’s use of milestones
  • Use of full functional specifications make it easier to work with remote developers

Cons:

  • Stifles collaborative creativity
  • Difficult to anticipate and plan for all customer requirements
  • Does not adapt to change well
  • Does not fold in all departmental feedback during the planning process
  • Takes a long time for something to be built
  • Designs often need substantial rework once they get to development

Iterative or “Agile” Product Lifecycle Process

Planning > Implementation > Testing > Feedback > Project Standups + Sprints throughout

An illustration of the Agile process (source: http://www.sohamgreens.com/process.html)

“Agile projects are paintings, not photographs.” – Unknown

“Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change,” (thanks again, Wikipedia!). Basically, Agile methodologies are all about focusing on getting features out into the wild as quickly as possible, and then learning from metrics and customer feedback. It encourages internal feedback from all departments, embraces speed and change, and eschews thorough documentation. Agile methodologies work best in cultures that respond well to change.

Pros and Cons of Agile Methodologies

Pros:

  • Encourages collaboration throughout the entire process
  • Fast development cycles called “sprints”
  • Products receive real-world market feedback quickly
  • Adaptive model makes responding to change easier

Cons:

  • Development spends more time planning, less time coding
  • Risk of releasing unviable features is heightened
  • Less time for market research and planning
  • Lack of documentation can prove challenging
  • Dangerous for mission critical projects due to iterative nature

So Which Product Life Cycle Process is Best?

Which product life cycle process is “the best”? The question really should be, which product life cycle process is best for your company. My next post will address why a company should invest in implementing a tailor-made product lifecycle process; and future posts will detail how to determine which product life cycle process is right for your company (SPOILER ALERT: it’ll most likely be a mix of the frameworks above), and how to properly roll it out to the company.

Next up in the Product Life Cycle series:

Part II: The Benefits and Risks of Implementing a Product Lifecycle Process

User Experience isn’t Everything

It seems the whole world has gone crazy for design lately. Engineers fancy themselves UXperts, Ad Sales is requesting PSDs to tweak, and Upper Management just doesn’t like that shade of blue.

Personally, I blame Pinterest.

Pinterest’s rapid ascent into mainstream lexicon* is enforcing the concept that the visual aspect is the only important piece of a product. Well, I’m here to tell you that that ain’t true.

Take the ‘To Do’ app Clear for example — it offers one of the most beautiful experiences available in the App Store. However, it’s also missing major features! It limits characters to an unusable minimum, there’s no indication of navigational hierarchy, the ‘down’ swipe intended to change screens constantly pulls down the iOS drop screen instead, and once you remove your completed tasks there’s no way to recover them (which is really annoying if you do it with an experimental swipe!!).

Path is another gorgeous app with insufficient use cases. The idea behind Path is that it’s the social network that limits your number of connections, thereby keeping your friend list to only your nearest and dearest. Well, that’s all well and good, but good luck trying to figure out how to post on another person’s Path! Instead of encouraging users to interact with one another, the featureset encourages them to fixate on their own Path. It quickly devolved into what Facebook began as — the pool into which Narcissus tumbled (complete with self-indulgent duckface photos to boot).

It’s been touted in the industry that 2013 is the ‘Year of Visual Web’ based on Pinterest’s continued success, redesigns by eBay that put imagery first, Facebook’s purchase of Instagram, and more. With the growing focus on aesthetics, let’s just hope people don’t forget about the features.

——————————————————————–

*A bit of an aside, but according to the New York Times, young women are driving linguistic change more than any other demographic. And ~80% of Pinterest users in the US are female. Hmm…coincidence?

#Rewind2011

I remember telling myself that 2011 would be my best year yet last January 1st, and I’m looking toward 2012 with the same optimism and enthusiasm! 2010 had been a rather placid year for me, and I was ready for some action. Here are my 2011 monthly highlights:

January: Social uprising hits home — literally — as friends and family are evacuated from my hometown of el Ma’adi, Egypt. On a more positive note, I obtained a certificate in Practical Product Management from Pragmatic Marketing, Inc., and launched the Mindjet Developer Network website, as well as revamped the Developer Program. My efforts led to a 300%+ increase in membership and the development of over 15 new software add-ins.

—

February: Flew out to DC to interview with a “deal-of-the-day” website giant, and ended up turning down their offer. Sometimes even when the money and the role are right, the company culture just feels wrong. In the end, I’m very glad I didn’t take the position.

—

March: What can I say? March is always awesome because it’s my birthday month! This year was especially special because I drove down to Pasadena to celebrate my pal LM’s bridal shower.

—

April: Drove down to LA with my BF to pick up his two best friends, and then onto Vegas for some gamblin’ and the Hoover Dam for some history to make for an epic birthday trip! [Sorry, no Vegas pics allowed! ;)]

—

May: Ran Bay2Breakers and attended LM’s absolutely amazing wedding. Definitely one of the major highlights of the year.

—

June: Two major product launches in one month — you can believe I hadn’t slept for at least a month. Version 1.0 of Mindjet for iOS launched on the 14th, and MindManager for Mac launched on the 23rd!

—

July: Smat’s goodbye party as they head off to Germany.

—

August: Traveled to the Big Apple for an interview; spent a couple of weeks exploring New England with the BF and reacquainting myself with the Atlantic.

—

September: Accepted a new job in a new city; resigned for the second time in my life.

—

October: Moved to NYC on the 2nd, and managed to find, sign for, and move into my new apartment on the Upper East Side within 6 days. That was intense (and quite possibly some kind of record). I also founded the very first ProductCamp San Francisco, an annual educational and networking unconference for local product management and marketing professionals, on 10/22.

—

November & December: A few visits from friends and family in the area, and a LOT of exploring in my new city!

  


—

I hope you all had just as epic of a story to tell for #Rewind2011! If not, there’s always 2012 to make up for it.

The Basics of Product Management

Many people don’t realize that product management is a relatively new role in organizations. Until quite recently, different aspects of product management were performed by a myriad of functions across organizations. Business analysts, project managers, program managers, quality assurance engineers, and customer support all pulled together to fill the void and carry a product from inception to launch. But even now that “Product Manager” has become a common position in many industries (and quite the commodity for recruiters), the role remains unclear to even those who fill it. Many product managers still seem to think of product management’s role as a glorified Project Manager, or some amalgamation of User Experience, Quality Assurance and Customer Support. That’s why I’ve compiled a short-list of product management basics below as a guideline.

An effective product manager is responsible for accomplishing the following things:

Identifying Market Opportunity

We’re the folks who determine whether anyone actually wants to buy what the company’s selling. We determine market problems, investigate the competitive space, and thoroughly analyze industry trends. We are the folks who should be up-to-date on every single detail that could affect what our customer base wants or how it behaves.

We’re also supposed to do customer visits, prospect visits and attend industry events; generally speaking, this is where product management is least successful. Although PMs prefer to send out surveys, pore through customer emails and occasionally take a customer phone call, it’s not only their fault the profession is largely lacking in this area. Many companies are not willing to invest in gathering this (the best) kind of data. Product Managers need to attend events and spend time with current and prospective customers to find out what does and doesn’t work about the product. This is where VPs of Product need to step up and fight for the budget to allow their team to accomplish these tasks, as well as to push their team to do these visits and events on a regular basis. It’s best to set a quarterly quota of visits the team must make — it keeps ’em honest.

Defining the Product Roadmap

Product Managers must define exactly what goes into the product and at what times. We don’t technically decide when each new featureset will be released, considering Engineering determines the product RTM date and Marketing is responsible for deciding the exact GA, but we can heavily influence those dates, if need be.

We define each release to include some business and strategic opportunities, a few customer suggestions and as many bug fixes as we can squeeze in. The only problem when gathering market feedback is that everyone thinks they’re an expert, and each person’s pet peeve becomes a PRIORITY 1 MUST HAVE from their point of view, and the release is a disaster if it’s not included. Product managers must learn to hear the noise, and see the trend. And slap a few wrists.

Gathering Requirements

This is the most well-understood portion of a product manager’s role. Most people would identify writing requirements as the product manager’s domain. What they don’t see is the backend of the PM’s effort. We not only gather requirements, but we define use cases and user flows, argue business cases, and become masters in the black art of pricing.

Monitoring Product Performance

Even after release, the product manager’s job is not done. We spend a big chunk of our time tracking released products, because it gives us better insight into the subsequent releases. We follow market and customer KPIs (Key Performance Indicators) to help with forecasting future releases. KPIs consist of various performance metrics, such as regional market performance, market segment consumption, % revenue from new products, % revenue from new customers, ASP (average selling price), customer usage, number of trials and subsequent rate of conversion, and renewals. All the KPIs help inform the Win/Loss analysis, which marks the beginning of another product lifecyle. And then we do it all over again. 🙂

Of course, I recognize that I am leaving out key components of product management, such as interpersonal and communication skills, leading without direct authority, managing up, growing feature backlogs, technical aptitude, and a great many other things, but I’ve touched on the four basic activities an effective product manager must perform in order to launch successful products.

Announcing: ProductCamp San Francisco!

I’m very proud to announce the date for the inaugural ProductCamp San Francisco! With the help of some industry veterans, I’m hosting the very first PCamp SF at the Mindjet headquarters on Saturday, October 22nd, 2011.

For those of you who aren’t familiar with this wildly popular phenomenon, ProductCamp San Francisco is a FREE collaborative, user-organized unconference focused on Product Management and Marketing topics.

At a ProductCamp everyone participates in some way: presenting a session, leading a round table discussion or showcasing a best practice. Others help with logistics, organizing sessions, or setting up/cleaning up. This is a collaborative event designed to be a fun, rewarding and unique experience.

ProductCamps have no predetermined agenda. Sessions are chosen on the day by voting on the topics that most interest you (propose a topic).

For more information (or to sponsor or volunteer), check out our website!

Stephanie’s blog launch!

Welcome to the inaugural posting of Stephanie’s blog! I will focus most posts around business and marketing topics, as well as document important events in my personal life, including my extensive travels. Think of it as an autobiography illuminated by posts following my personal interests: business, marketing, high-technology, and international relations.