About

Product Management and the inspirations around it - a Malaysian point of view.

Friday, February 19, 2010

Dedicated Product Teams

Article: Dedicated Product Teams

In my last article (see http://www.svpg.com/knocking-down-walls/) I talked about the importance of knocking down walls, especially the wall between product management and engineering.  In this article, I want to describe a technique that helps achieve this, along with several other significant benefits.

While there are many variations, there are essentially two common ways of running your product organization.  The most common of the two is to do some form of project-based planning.  In this model, the management of the company essentially defines a communal roadmap – they come up with a prioritized set of projects for the quarter or year, and they allocate time and people to those projects.  For example, they may have a team spend two months working on a new advertising system, and then the next high-priority project for that team might be a new search technology, or some SEO work.  The team may or may not change, but the project and even domain they are working on typically changes frequently.

Basically if you look at the communal roadmap, you see a mosaic of different projects, each row typically an allocation of a set of developers to a project.

These roadmaps hardly go a week without significant change.  Some new business opportunity comes in and takes priority, so that throws a big wrench in the plans and a bunch of shuffling is done, or a project takes longer than expected, so that has a ripple effect.  

(Not to mention that these project-oriented portfolio roadmaps are typically created before there is any real information or knowledge on what it will really cost to build this, and whether customers will actually want to use it.  But that’s a different issue.  See http://www.svpg.com/your-business-plan-is-wrong/).

These communal roadmaps change so frequently are are so full of assumptions that they’re rarely something companies enjoy, but nevertheless this is often how they run their product organizations.  There are, however, several less obvious consequences of this approach.

First, teams are constantly moving around.  Product managers team up with specific developers on a project basis.  Often they don’t have nearly the time they need to form the working relationships so important to effective teams.

Second, the developers are often constantly reassigned to different areas.  While on the positive side the developer gets exposed to lots of different areas, they often don’t get the time to develop the deep expertise in an area that can make a developer so incredibly valuable.  

Third, since the developer is switching topics so frequently, they don’t develop the velocity that an experienced team does.

Fourth, since the developers are scheduled on different projects beginning right after the prior project ends, this tends to encourage what we call “release and forget” where a project is launched because it is scheduled to launch, but the follow-on work and the product optimization work gets deferred for months or even indefinitely because the team is on to other projects.

The alternative to this, which I’m happy to say is spreading fairly rapidly across our industry, is to move to dedicated product teams.

In this model, the executives, rather than debating specific projects, instead consider which areas of the business they want to invest in, and what percentage of resources to allocate to each area.  For example, for a typical e-commerce company, they might have teams like “Search and Recommendations,” “Product Pages and SEO,” “Fulfillment Systems,” “Infrastructure,” “Rapid Response” and “New Business Opportunities.”  They would then choose what level of investment they consider appropriate for each area.

The next step for the management team in this model is to define Product Team Scorecards for each of the teams (see http://www.svpg.com/the-product-scorecard/).  This essentially sets the business priorities for each of the teams.

Next the organization staffs the teams with a product manager, user experience, developers, and QA, in proportion to the allocation decided above.

In this model, the team then is charged with coming up with the projects, features and fixes that they believe will best deliver on the KPI’s defined in the Scorecard.  

There are two important differences here.  The first is that these teams are ongoing.  They don’t switch from topic area to topic area after every project.  Instead, they focus their energies on building true expertise on their topic, and coming up with real innovations in their areas.   The second is that the team members are persistent, in that they are assigned to this product area and they’re not just here for the specific project.

Of course management may choose to adjust the balance of resources by reallocating people, or by adjusting the Scorecard to reflect changing business priorities – this usually happens quarterly or annually.  And of course people are not sentenced to work on this area for the rest of their career.   They can and should move between teams, but generally people are working on a team for a year or so, and not just for a few weeks or months.

As I watch companies switch to this model, I consistently see the velocity go up as the teams gain expertise.  I also see the quality of product go up dramatically which I attribute both to the relationships that are built and also to the sense of ownership that teams feel over their area.  But most importantly, I see the business results that stem from the focus, the better product work, and from continuous and rapid improvement of the product.

A few notes:

- A very useful dedicated product team is the “rapid response team,” there to handle critical fixes and relatively minor improvements and functionality.  I’ll describe this in more detail in an upcoming article.

- I also like a “new business opportunities team” that is there to explore new potential products or sources of revenue.  In most companies, these opportunities will always arise, and if you don’t have a team available to pursue, then all too often other teams are raided for resources.  Instead, plan for a small team to pursue these opportunities, and help them get good at evaluating potential.

- The one team and allocation that’s usually a given is the “infrastructure team.”  This is a special team, usually comprised of just engineers and architects, and the allocation is typically 20% for consumer internet companies.  You can instead intersperse this work into the other teams, or you can have a blend (a dedicated team plus some resources in each of the other teams).  See http://www.svpg.com/engineering-wants-to-rewrite/.

- Moving to Scrum, if you haven’t already, will get you part-way towards dedicated product teams.  It helps a great deal in building the personal relationships of an effective team.  But all too often, Scrum teams are still handling backlog items from many product areas, and not being given the ability to focus on an area as a team.  That’s the difference really between a project team and a dedicated product team.


While I typically recommend moving to dedicated product teams for the full product organization, be warned that this is not a trivial change and requires executive support.  If your organization is not yet convinced, you can move just one or two teams to the dedicated product team model.  If you give this model even 6 months I’m fairly certain you’ll see the benefits and hopefully make the switch at the next planning cycle.

You can find all articles at www.svpg.com/blog. />

Posted via email from Great article collection for Product Managers

Sunday, September 27, 2009

How to present like Steve Jobs

You can watch the video here, and read my excerpt below.

This is from a book The Presentation of Steve Jobs by Carmine Gallo.
How to be insanely great in front of any audience.

5 key secrets

1. Introduce the antagonists

"Every great drama has a hero and a villain."
This is the key to great salesmanship isn't it. Sell the problem first, then the solution. Many people do it the other way round!
The villain here can be a customer problem, an ugly scene in the industry, or a competitor.
And make your solution the Hero.

2. Create Twitter friendly headlines.

"A really light, thin notebook with a 13.3 inch display and yada yada yada" versus
"The World's Thinnest Notebook". (Period).
That was the headline for MacBook Air. 140 character or less!
The next key is - how you communicate that consistently across your website, press releases, presentations, and what came out from your sales person's mouth. I think it takes good discipline and great leadership in the organization.

3. Sell Dreams, not Products.

Steve Jobs doesn't sell computers or hardware.
He sells transformative experiences.

"Music is a transformative experience. Music enriches people's life. In our own small way, we are changing the world". And the world was changed with iPod.

What is it about your product that will change your customers' life?

4. Zen like Simplicity

Simplicity is the elimination of clutter.
Simplicity is the ultimate sophistication.
Get it?
There are no bullet points in Steve Jobs presentation, and hardly any words. But yet every slide of his presentation conveys a strong message and maximized the outcome.

That same principle applies in product design, presentation and I dare say - life!

5. Rehearse!

Steve Jobs practices over 100 of hours over period of weeks before he does 1 presentation.
If Steve Jobs rehearse relentlessly, what would you do? Depend on your natural born talent in presentation?

Thursday, July 2, 2009

Ministry of Health Malaysia - Do you need a Usability Specialist?


Mark told me about this not long ago.. but I get to see it myself returning from Singapore last week.

As part of Ministry of Health's measure to curb the spread of Influenza A(H1N1), they now require all incoming travellers to fill in a form (on the left).

And it looks like they could use some good usability advice when designing the form - because many people have issues filling it.

First mistake, asking Age in form of _____ years and _____ months. Sorry, but it took me a while to count how many months old I am (is it the fault of our education system?).

Here's the real bummer - "Have you been to any area of country with local transmission of Influenza A(H1N1) as indicated by the WHO over the past 7 days?". Does everyone remember the full list of countries with local transmission of H1N1? The WHO list, you know?

So Ministry of Health, if you need to hire a Usability Specialist, please go to http://www.jobstreet.com.my/ - the most cost effective way to hire in Malaysia.
Or, get a hold of the book Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

Wednesday, June 10, 2009

The Marketing Discipline

Recently Philip Kotler was in the country to give a talk.
And I thought he said something very profound - Marketing needs deep understanding of the following:
  • Economic theory.
  • Mathematics.
  • Organizational theory.
  • Behavioral science / psychology.
Does the marketing function in your organization capable in all these areas?

Monday, April 6, 2009

Assessing Product Opportunities

"Complicated is interesting, Simple is useful' - I heard this recently. The best advice is normally the simplest one, isn't it?
So I was thinking about how can I systematically access the potential of a new product, and I found a good article in SVPG (yet again).

And here's the thought process - guiding questions to help discover the answer:
1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

Tuesday, October 7, 2008

Moving from Enterprise to Consumer

I found this article on SVPG and I think it's useful for my friends who are moving from creating / managing enterprise level products to consumer centric products:

"
Occasionally a company starts its life as one type of business but then finds that they need to change into another type of business.  The most common such transition I see is to start by building products for very large companies (enterprises), but then decide you need to switch (or expand) to sell to consumers and/or small businesses.

Even before the recent turmoil in the financial services industry, I was often asked by enterprise CEO’s how can they change course to a consumer company. Or, I would be asked by product managers how to make the move from product management in an enterprise company to product management in a consumer internet company. 

There are many potential reasons for this.  

It may be because the company has saturated the enterprise market.  Or because they determine that there simply aren’t enough companies out there with pockets deep enough to pay what they would need to survive.  Or because their investors point to the dramatically larger market of consumers and small businesses and say that’s the new objective.  Or sometimes companies simply tire of their fate being driven more by deals on the golf course, rather than the fruits of their product efforts.

For whatever reason, if your company decides it must evolve from an enterprise business to a consumer business, then I’ve learned that there are several things that you can do to increase your chances of success.  

I will warn you however that changing your company like this might sound easy but let me assure you it’s not.  In fact, most companies don’t survive the transition.   Unfortunately, often this transition is necessary, so the business may not have any choice but to try to change.

Note that much of this also applies to product managers that wish to transition from working in an enterprise software company to a consumer software company.

Corporate DNA

First, realize that whether intentional or unintentional, your company is surely populated by many people that have spent their career in enterprise businesses, and that’s the world they know.  

There are clues to this all over the office.  Do you see anyone with ties on?  Do you have a direct sales organization?   Does the company have a box at the local arena to entertain clients?  Do you have a customer briefing center?  Is your company name along the side of some race car or sailboat?   Is the role of marketing at your company to support the sales force?  Do you see a lot of specials?  Are there a handful of very big customers that cause the entire company to bend over backwards?  

At a superficial level all of these things may seem easy to change, but they stem from deep down beliefs about how to run a business and how to attract and retain customers.

Start at the Top

The CEO must tackle this DNA issue head on and take a hard look at the culture and the organization and consciously set the new tone.  This will almost certainly require some new blood on his or her staff with the new DNA.

But it’s also almost certain that there will be people in the company that will resist these changes, and push back hard.  Many of them see the writing on the wall and know they are fighting for their jobs.  Fortunately, many of them have long wanted to make the switch to consumer but with their enterprise experience have had trouble finding a company to take them.  If your company is willing to teach them what they need to learn then they can often become strong supporters.  But honestly those that don’t want to move will need to be moved out of the way. 

Consumer Companies

I’ve written earlier about what makes a great consumer internet service (see http://www.svpg.com/blog/files/consumer_internet_services.html) so I won’t repeat that here, but I will emphasize a few key points:

- You only survive if you create a product that hundreds of thousands if not millions of people want to use.

- With consumer products, every customer is a user, and as such, every user makes the decision to purchase or use.

- It’s all about scale – the ability to scale the software, to scale the marketing/customer acquisition, and scale the customer support processes. 

- In an enterprise company, it’s really mostly about sales and the sales organization.  In a consumer company, it’s all about product, with a good dose of online marketing challenges as well.

- Because you can’t depend on training classes, online tutorials, or an SE to hold the hands of the new users, the product has to be dramatically easier to learn and use.  This means building out a user experience team that knows how to design this type of software, and a product organization that knows how to work with this team to define, design, build and run this software.

- In an enterprise sale, you may have charged on average say $100K in license fees with $25K in yearly maintenance, and of course the marginal cost of the software is essentially zero, so there’s plenty of room for the sales rep, the SE, the big dinners with the client, the time required for custom RFP responses, the special visit the engineer makes to customer to help get the software working, etc.  But for a consumer or small business sale, for say $25/month/user (and realize that most consumer or small business revenue is actually significantly less per customer), you obviously have no room for such luxuries on a per customer basis.  Even at $250/month per small business you have no such room.

- In consumer products, the software absolutely has to actually work.   No more leaning on professional services or SE’s or integration partners to glue things together for the customer.  It has to work, work well, and work immediately.   Exceptions to this will destroy your customer service costs and erode your margins.

Back to the Culture

Much of what I’m describing above has to do with skills and best practices, but a lot of this is really about the culture, and I think that not enough companies attempting to make this transition pay enough attention to the cultural aspects.

Remember that in the consumer software company culture, it’s not about ties or sales or big customers, it’s about how many people are loving the product, how do you make the product even better, how do you get people to engage even more with the site, and how do you continue to get the message out to others that will love the product.

Once companies truly get this, they usually end up significantly reducing the size of the sales and sales support organization, and significantly increasing the size of the product and marketing organizations.

You can find related articles at www.svpg.com/articles.
"

Sunday, August 17, 2008

Entrepreneurial Proverbs

Article by Marc Hedlund, Chief Product Officer of Wesabe.

Starting
  • It's good to be king -- being an entrepreneur is the best job I've had. Every day your job is new and different; you constantly have to push yourself in new directions. You no longer have to say, "Well, I'm just an engineer, but..." -- you have a great excuse to take an interest in everything. Working in an environment you shaped to your own beliefs about how a company should be run is incredible (and humbling!). And of course there are sometimes financial rewards, although it's still a great job regardless.
  • Losing sucks -- shutting down a company is unbelievably difficult. It affects your home life, your health, your job prospects, your financial stability. Professional investors are grown-ups, but it's still extremely disheartening to lose the money people invested based on belief in you. If your backers include friends or family, it's extremely difficult to have to tell them the company is closing and their money is gone. Most entrepreneurs fail several times before succeeding, too, so losing is both terrible and nearly inevitable. Fight as hard as you can against it.
  • Building to flip is building to flop -- this is taken from Jason Fried, and he's right. People who start out with only one goal, to sell to a big portal, will find their options are too limited. Plan as many paths to success as possible for your company, and always have a Plan B when acquisition (or whatever path you choose first) doesn't work.
  • Prudence becomes procrastination -- it's great to research your market and talk to potential buyers about your ideas. It's terrible to let an excess of this become a impediment to getting started. Too much prudence edges away from research and into procrastination.
  • Momentum builds on itself -- just start. Do whatever you can. Draw a user interface. Write a spec. Make something, anything, that people can see and touch and try. A prototype is worth ten thousand words. Once you start moving, you will find that people start to carry you along.
  • Jump when you are more excited than afraid -- lack of fear is irrational, and too much fear is debilitating. Make the jump into your business when you have considered the fear, and come out more excited than afraid.
The Idea
  • Pay attention to the idea that won't leave you alone -- this is taken from Paul Hawken's Growing a Business. Sometimes an idea catches hold of you and you find you can't put it down. Pay attention to that! Just start working on it. Can't get yourself to do anything on it? Move on. Find yourself waking up out of bed to write down new ideas about it? That's a good one to choose.
  • If you keep your secrets from the market, the market will keep its secrets from you -- entrepreneurs too often worry about keeping their brilliant secrets locked away; we should all worry much more about springing a surprise on a disinterested market (anyone remember the Segway?). To quote Howard Aiken: "Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats."
  • Immediate yes is immediate no -- does everyone immediately tell you your idea is great? Run away from it. If the idea is that obvious, the market will be filled with competitors, and you'll find yourself scrambling. One good test: when the New York Times Magazine puts out its annual "Year in Ideas" issue, is your idea in it? Then don't do it. You're already too late.
  • Build what you know -- this is the most basic advice of idea generation: scratch an itch you have yourself. To make a great company, stop and ensure that your need is broadly felt, and that your solution is broadly applicable -- not everyone spends their life in front of a computer, remember.
  • Give people what they need, not what they say they need -- interviews are tricky. People will swear up and down that they would buy a product you describe if only it were available, and then fail to do so as soon as it is. Likewise, in conversation an idea can sound terrible, but in actualization the idea can become a compelling product. You have to sherlock out the truth of the interest people express, and "yes/no" questions are usually less useful than "how much" or "how bad" questions.
  • Your ideas will get better the more you know about business -- engineers hate to hear this, but you can generalize up quite far from here: the more you know about everything, the better all of your ideas will get! If you want to start a business and your strength is in development, learning about pricing, sales, marketing, finance, and yes, even HR, all of it will make your product ideas stronger and better.
People
  • Three is fine; two, divine -- having too many co-founders makes decisions hard to reach; if you're on your own, you have to bear all of the stress and worry about the success of the company. In my judgment, three people can do well together, but having two founders is best.
  • Work only with people you like and believe in -- I once heard Eric Schmidt say something along the lines of, "The older I get, the more I think all that matters is working with people you like." If you're smart and talented, you're probably going to like a lot of smart and talented people. Working with people you like is so much more fun, and often more productive, than fighting against someone who may be smart and talented but just isn't a great fit for you.
  • Work with people who like and believe in you, just naturally -- maybe you are very persuasive, and can talk people into working with you against their better instincts. Especially for co-founders and early employees, don't try that hard. Find the people that naturally want to work with you, and nudge them into the roles where you need them. You'll have more fun and get more done.
  • Great things are made by people who share a passion, not by those who have been talked into one -- a corollary of the last; you can spark a passion in someone, but you can't do it without some fuel to catch. Better to wait, and find the person who is already inclined to believe in your cause. You may talk someone into co-founding a company with you, but will they stick with it through ups and downs if they had to be persuaded that hard?
Product
  • Cool ideas are useless without great needs -- this is the classic engineers' entrepreneurial mistake (or at least I'd like to think so, since I've made it). Techies love tech, and a new technology can produce a lot of companies that don't really meet a need. Better to start with the need, and then see how what you know can produce a better answer to that need. (Marketers tend to have the opposite problem: real, pressing needs with completely unworkable solutions.)
  • Build the simplest thing possible -- engineers have the hardest time with this, with not overdesigning for the need they're addressing. Make the simplest possible product that makes a significant dent in that need, and you'll do far better than you would addressing two or three needs at once. Simplicity leads to clarity in everything you do.
  • Solve problems, not potential problems -- you can waste a lot of money implementing solutions for problems you don't have yet, and may never have. Work on the biggest, most pressing problems today, and put aside everything else.
  • Test everything with real people -- it's unbelievable how helpful this is. Go find civilians, real people who use computers because they have to and not because they love to. Find them in Starbucks, or at the library, or in a college computer lab. Give them $20 for 20 minutes, and you'll be paid back a hundred times over.
Money
  • Start with nothing, and have nothing for as long as possible -- small budgets give big focus (probably another line I'm stealing from Jason Fried: it sounds like something he'd say...) Don't go out and raise a ton of money right away. Instead, give yourself just enough to get going, and use the limits that imposes to motivate yourself.
  • The best investor pitches are plainspoken and entertaining (not in that order) -- think about what this implies. A plainspoken pitch is the surface of a very solid business. If you have to fudge and lie to get investors interested, why is that? If you're running a great business, it is not hard at all to lure investors into it; the worse your business, the bigger (and more odious) your fundraising task is. Entertaining implies a fun person to work with, and VCs like working with people they like as much as the rest of us do. If you don't bring the funny, bring the person who brings the funny.
  • Never let on that you're keeping a secret -- telling an investor "I don't want to talk about that" is terrible. It's the natural converse of being plainspoken. It's good to be aware, though, that some potential investors will listen to you and then share your information with your direct comptitors, and not always because they're invested in those comptetitors. Knowing that, you have to keep some secrets -- but be as diplomatic about that as possible. Respond to the idea behind the question, without giving away more than you feel comfortable discussing. Learn to steer the conversation in the way you want it to go. And then give up more information as you become more comfortable with the potential investor.
  • No means maybe and yes means maybe -- you should never take a "no" from someone you want to work with. Accept the no, ask for feedback, and then just keep sending them updates on how much butt you're kicking in the market. During one company, three of the five term sheets I collected came from VC firms that told me "no" originally. Conversely, though, the only money in the bank is actual money actually in the bank. Everything else is just a possibility, and you have to treat it as such. Don't stop fundraising until you have a firm commitment for the funding you need, and don't accept halfway promises like, "We'll fund you if another firm comes in." Keep on driving until the wire transfer is complete.
  • For investors, the product is nothing -- the classic engineer's VC pitch has ten slides about the product and two about the academic achievements of the founders. That's a terrible pitch. One slide should be about the product, while the rest cover the market, competitors, financials, funding history, and the relevant experience of the team. The product matters far less to most investors than the reactions of customers, the properties of the market, and the credibility of the team. Obsess about the product on your own time; present your business in all of its parts.
  • The best way to get investment is not to need it -- if you have a running business with real customers and you're paying all your bills, you are much more likely to get a funding round than if you need the round in order to survive or succeed. The pitch that goes, "We could accelerate our growth with more money" is much more compelling than, "I need your money or our doors will close."

I'm sure other people have their own rules of thumb; what are yours?