What Every Startup Employee Should Know About Finance

If you work at a startup, you know that your role is probably bigger than what was in your initial job description. This provides a great opportunity to learn outside of your role — and startup employees should embrace knowing a bit about all the functions that make the company run.

In my role at High Alpha, a venture studio, I provide finance services to the companies we launch until they’re ready to hire a full-time finance leader. I’ve been asked by coworkers if all I do is look at numbers all day, and while my job involves its fair share of spreadsheets, the high-level strategy is much more interesting. In an attempt to demystify finance in a startup, I’ve broken out four areas that every startup employee should know about finance.

1. Forecasting and Budgeting

And why you should turn in your expense report on time

In a startup, plans can change in the blink of an eye; even so, the business still has to have a high-level roadmap, and it’s all managed in the financial plan. This forecast (yes, often an Excel document) shows month-to-month sales goals, hiring plans, and other expenses. Most importantly, based on these plans it predicts when the company will run out of cash (assuming it’s not yet profitable), and when they will need to raise a round of funding.

The finance team should help the company find the right balance of setting high, yet achievable sales goals, and budgeting costs to provide needed resources without burning cash too quickly. The team should continuously keep its finger on how the company is doing relative to plan. To do that, all actual expenses need to be gathered at least monthly to make sure the company is in line with plan, and call out any discrepancies before the company is in trouble. This is why timely expense reports are important — the company can only make informed decisions about future spending if it knows how much it’s spent presently.

As a startup employee, you make the cash come in and go out. Everyone on the team helps to bring in sales, whether directly in a sales or marketing role, or indirectly like in a product role (building the best product makes selling easier). Everyone also seems to have great ideas on how to spend money. But since your startup doesn’t have an endless cash supply, if you have an idea for spending money that’s not in the budget, think about the expense like the finance leader: will this cash investment either a) generate sales to cover the cost or b) is it worth burning cash and raising more funds sooner? Judging this second point is hard, but know that the more cash your company needs to raise from external investors dilutes your potential employee ownership in the company; if you have employee stock options, this means they will be worth less — but more on that later.

2. KPIs (Key Performance Indicators)

Certain numbers and metrics serve as the report card of a startup, and the finance team is often tasked with tracking, analyzing, and benchmarking these metrics. By watching and analyzing these numbers and their trends, we’re able to provide insights to company leaders to facilitate decision-making.

KPIs will vary depending on the industry and stage of your company, but there are a few big buckets of metrics that transcend all startups.


One bucket is cash. Knowing your cash burn, how much your bank account is decreasing each month, is important for obvious reasons — running out of cash is the worst thing that can happen to a startup. Measuring cash efficiency — how much cash you’re burning per dollar of revenue you’re generating — is also important to watch for trends. As an employee you may not know the total cash balance or monthly burn, but know that this is (or should be) top of mind for your company’s leadership.

Revenue & Growth

Another set of KPIs centers around revenue and growth. Venture-backed startups are focused on growing revenue quickly. In the SaaS and subscription world, annual or monthly recurring revenue (ARR or MRR) is the key number to track.

Customer Satisfaction

The team should also be evaluating customer satisfaction. In SaaS, we’re looking at customer churn rates, and determining the lifetime value of customers based on how long they stick around.

Investors also care about these KPIs. They’re comparing your company’s cash efficiency, revenue growth rates, and customer churn to other companies in the industry and deciding whether they’ll invest. For this reason, it’s important for company leaders to know what the ideal benchmarks are, and the finance team should help the company set goals and meet these benchmarks through a strong financial plan.

3. Fundraising

The very generic, big-picture rhythm of a successful venture-funded startup goes something like this: the company starts out with some sort of funding to build an MVP and maybe acquire a few customers. Then it raises a round of funding to hit certain milestones (sales milestones, product milestones, or both). It repeats with fundraising and hitting milestones until it becomes profitable or exits in some way (acquisition, IPO, etc.).

As an employee at a startup, you may not be directly involved in the fundraising process, but knowing the basic process should help you better understand the bigger vision of the company and give you a greater appreciation for the cash the company is spending — because fundraising is hard.

Companies need to start fundraising 6+ months before they need the cash. Pitching and finding the right investors takes time and is exhausting. Once you have investor interest, they will require some sort of diligence process, especially in later-stage companies, looking through the company’s metrics and financials (see previous two sections). Then there’s the legal process of setting the terms of the round and the valuation.

Founders are selling a piece of their company in this process; therefore, they’re looking for the highest price for the smallest portion of the company they can sell. This is why raising the most cash possible isn’t always best; sure, more cash gives the company more runway, but it also gives more of the company away. This is called dilution, and if you have employee equity, it affects you directly. Which leads me to…

4. Equity and Employee Stock Options

Startups often give employees equity in the company — it’s a way to provide compensation without spending more cash up-front, and it helps align incentives. When the company does well and hits goals, it increases the value of the company and increases the value of the employees’ shares.

Understanding the workings of employee stock options and equity is important — you should know the terms around your option agreement, vesting schedule, and exercise price. There are many good articles out there explaining these topics, so I won’t re-invent the wheel here. Instead, I’ll tell you why you should care.

Your stock options represent the opportunity to own shares of the company. What the company is worth, and therefore what your shares are worth, depends on the company’s valuation, which is set and reset each time the company raises an equity round of funding. Hitting goals while being cash efficient leads to good KPIs, which leads to better valuations.

Because your startup isn’t publicly traded, you can’t sell your shares at any time. But if the company is successful, your shares will eventually become liquid, meaning you can turn them into cash. This happens when your company is acquired or goes public. And if it’s valued highly, your shares are worth more, and you get a bigger payout.

At a startup, every employee is a decision maker and is critical to the company’s success. You’re a part of building something — building a product, a culture, and a business. In this environment, it’s easier to learn about roles outside of your own and get a better picture of the full business. Keep asking questions, even if they don’t directly relate to your role. The more of the big picture you understand, the better equipped you’ll be to enable the success of the company in your role.

High Alpha is a venture studio pioneering a new model for entrepreneurship that unites company building and venture capital. To learn more, visit highalpha.com or subscribe to our newsletter.

6 Things I’ve Learnt In My First Year as a Product Owner

One year ago today I made the move from heading up Sainsbury’s Digital Corporate Affairs to Sainsbury’s Digital and Technology division and started my new life as a Product Owner.
I’d always thought of myself as a bit of a geek with a great passion for the web and digital so I was very excited (and a year later, I still very much am!) to be given the opportunity to tackle this new challenge.

To celebrate my one year anniversary as a Product Owner, I thought I’d list the lessons that have stuck with me.

1. Ask Questions Rather Than Saying ‘No’
Ideas and feature requests for your product will come from all over. As a new Product Owner, my first reaction was to say yes to everything. While that kept people happy in the short term, I was soon faced with a massive backlog of stories and no way to deliver them all.
Rather than saying ‘yes’ immediately, responding by asking questions is a useful tool. It helps me understand more about the request. I can dig a bit deeper and learn about why they think something is a good idea for my product. What do they think it will achieve? How do they envisage it working? What are they looking to achieve? You get the idea.
If an idea makes it through this kind of positive challenge, I’ve found that it will actually be useful and valuable for my product. As part of the conversation, I’ll have learnt a good amount to craft the beginning of a user story with acceptance criteria. Also, the context and reasoning will help me rank how this new feature compares to existing ones in my backlog and how it should be prioritised.

2. You Don’t Know What You Don’t Know
An odd one I know, but while we’re on the subject of questions, as a new Product Owner who’d only heard about Scrum, Agile, Sprints, Jira, Slack in theory — there were some questions that I simply didn’t know to ask!
Questions you’ll only know to ask once you’ve launched a product, once you’ve gone through a round of testing, how to build a roadmap, how to run a product demo. As with any other job, experience next to academic learning is key and will only come to you with time!
I was lucky to have join a team with an experienced Product Owner at the helm who has helped me along this journey of experience, introducing me to the right people and processes. As a result, I feel more confident after having launched my first product in my first year and from the many interactions with colleagues across the division.

3. Break Stuff
Leading on nicely from my previous point, my boss has a very useful knack for picking apart my product in a productive way. Have you thought about this? What if this happens? What are your dependencies? What’s your plan B? A hugely useful process I found, and it’s turned into a bit of a mantra for me. Break stuff in a safe environment before it goes to a wider audience.
I’m reminded a little bit of my days in Corporate Affairs where a healthy amount of cynicism helped in separating the good stories from the boring and always preparing for the worst.
Much like producing a robust Q&A document to arm people against tricky media questions, the goal is to get to a place where you have picked apart your product to such a degree that what’s left fits together perfectly, delivers a great experience and meets business objectives.
4. Communicate, communicate, communicate
I didn’t appreciate how much time I would spend talking to people as a Product Owner. Be it refinement sessions with my scrum team, clashing roadmaps with other product owners, discussing the nuts and bolts with architects, getting to the nub of what stakeholders actually want, customers… Chances are you should stop reading these words and talk to them immediately.
As a product owner, I am responsible for my product. I get to make decisions — but I can only make those decisions if I take everyone on a journey with me. If everyone understands what the product is about. What it’s meant to achieve. If people don’t understand why I am making a decision, they likely won’t approve it.

5. Too Many Meetings
A consequence of having so many people to talk to and working in a big organisation like Sainsbury’s means that I had too many meetings and not enough time to actually do any work.
This is a tricky one and I don’t think I’ve cracked it yet. I try to make sure that Agile ceremonies are booked as far in advance as possible and I also make sure that I have a set amount of time a day blocked to do work.

6. Paper
In this least year as a product owner I have spent more time sketching and drawing than in my five years in the Corporate Affairs team combined. There’s an irony to the simple fact that in order to build a digital product in an Agile way, you’re going to end up using a lot of paper.

Good Product Team / Bad Product Team

NOTE: My friend and colleague Jeff Patton is the author of an upcoming book on the general topic of User Stories and especially the technique of Story Mapping.  I was asked to write a foreword for this new book, and this article is an excerpt from the foreword.  I was also a reviewer of the book and it is definitely a must-read for any product person and fills a very big gap in the current library of Agile titles.  If you’d like to pre-order the book you can do so from O’Reilly.

I’ve had the extremely good fortune to be able to work with many of the very best technology product teams in the world. People creating the products you use and love every day.  Teams that are literally changing the world.

I’ve also been brought in to try to help with companies that are not doing so well.  Startups racing to get some traction before the money runs out.  Larger companies struggling to replicate their early innovation.  Teams failing to continuously add value to their business.  Leaders frustrated with how long it takes to go from idea to reality.  Engineers exasperated with their product owners.

What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences.  Everything from how the leaders behave, to the level of empowerment of teams, to how the organization thinks about funding, staffing and producing products, down to how product, design and engineering collaborate to discover effective solutions for their customers.

With a grateful nod to Ben Horowitz’s classic Good Product Manager/Bad Product Manager, for those that have not yet had the opportunity to participate in, or observe a strong product team up close, in this article I wanted to try to give you a glimpse into some of the important differences between strong product teams and weak teams:

  • Good teams have a compelling product vision that they pursue with a missionary-like passion.  Bad teams are mercenaries.
  • Good teams get their inspiration and product ideas from their scorecard KPI’s, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems.  Bad teams gather requirements from sales and customers.
  • Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
  • Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building.  Bad teams hold meetings to generate prioritized roadmaps.
  • Good teams love to have brainstorming discussions with smart thought-leaders from across the company.  Bad teams get offended when someone outside their team dares to suggest they do something.
  • Good teams have product, design and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience and the enabling technology.  Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings.
  • Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test.
  • Good teams insist they have the skill sets on their team necessary to create winning products, such as strong interaction design.  Bad teams don’t even know what interaction designers are.
  • Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better.  Bad teams show the prototypes to the engineers during sprint planning so they can estimate.
  • Good teams engage directly with end-users and customers every week, to better understand their customers, and to see the customer’s response to their latest ideas.  Bad teams think they are the customer.
  • Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome.  Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.
  • Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor.  Bad teams complain they are slow because their colleagues are not working hard enough.
  • Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business.  Bad teams complain about being a sales-driven company.
  • Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data.  Bad teams consider analytics and reporting a “nice to have.”
  • Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers.  Bad teams test manually at the end of a painful integration phase and then release everything at once.
  • Good teams obsess over their reference customers.  Bad teams obsess over competitors.
  • Good teams celebrate when they achieve a significant impact to the business KPI’s.  Bad teams celebrate when they finally release something.

If too many of these items strike too close to home, I hope you’ll consider raising the bar for your team and see if you can’t experience the difference.

The Article is from http://svpg.com/good-product-team-bad-product-team/

10 Reasons of so many product failures

In this article I’d like to discuss the root causes of so many product failures.

I see the same basic way of working at the majority of companies, and I can’t help but notice that this is not close to how the best companies actually work.

Let me warn you that this discussion can be a little depressing, especially if it hits too close to home, so if that’s the case, I’ll ask you to hang in there.

Let’s start by walking through the process that the vast majority of companies still use to create products.  I’ll try not to editorialize yet; let me first just describe the process:

Everything starts with ideas.  In most companies, they’re coming from execs or key stakeholders or business owners, or big customers (or prospective customers), but in any case there are always a whole bunch of things that different parts of the business need us to do.

Now most companies want to prioritize those ideas into a roadmap, and they do this for two main reasons.  First, they want us to work on the most valuable things first, and second, they want to be able to predict when things will be ready.

In order to do this, there is almost always some form of quarterly or annual planning session where the leaders consider the ideas and negotiate a product roadmap. But in order to prioritize, they first need some form of a business case for each item.

Some companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: 1) how much money will it make? and 2) how much money or time will it cost?  This info is then used to come up with the roadmap, usually for the next quarter but sometimes as much as a year out.

At this point the product and technology organization has its marching orders, and they typically work the items from the highest priority on down.

Once an idea makes it to the top of the list, the first thing that’s done is for a product manager to talk to the stakeholders and flesh the idea out and come up with a set of “requirements.”

These might be user stories or they might be more like some form of a functional spec but it’s purpose is to communicate with the designers and engineers what needs to be built.

Once the requirements are gathered up, the user experience design team (assuming the company has such a team), is asked to provide the interaction design, the visual design, and in cases of physical devices, the industrial design.

Finally the requirements and design specs make it to engineers.  This is usually where Agile finally enters the picture.

Anyway, the engineers will typically break up the work into a set of iterations – called “sprints” in the Scrum process.  So maybe it takes 1-3 sprints to build out the idea.

Hopefully the QA testing is part of those sprints, but if not, the QA team will follow this up with some testing to make sure the new idea works as advertised, and also doesn’t introduce other problems (known as regressions)

Once we get the green light from QA, the new idea is finally deployed to actual customers.

In the vast majority of companies that I first meet, large and small, this is essentially how they work, and have worked, for many years.  Yet these same companies consistently complain about the lack of innovation and the very long time it takes to make it from idea to customer’s hands.

You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I’ve just described is very much a Waterfall process.  In fairness to the engineers, they’re typically doing about as much Agile as they can given the broader Waterfall context.

OK, so that may be what most teams do, but why is that necessarily the reason for so many problems?

What I want to do now is to connect the dots for you to show you why this very common way of working is actually responsible for most failed product efforts.

Now I could literally talk all day long about the problems with this process, but what I’m going to do here is share what I think are the “top 10” most serious problems with this way of working.  To be clear, I’m arguing that all ten of these are very serious issues, any one of which could derail a team, but many companies actually have most or even all of these problems.

1. Let’s start at the top – the source of ideas.  This model leads to sales-driven specials, and stakeholder-driven products.  Lots more to come on this key topic, but for now let me just say that this is not the source of our best product ideas.  Another consequence of this approach is the lack of empowerment of the teams – in this model they’re just there to implement.  Mercenaries.

2. Next let’s talk about the fatal flaw in these business cases.  Now to be clear, I’m actually in favor of doing business cases, at least for ideas that need a larger investment.  But the way most companies do them, at this stage, in order to come up with a prioritized roadmap, is truly ridiculous. Here’s why. Remember those two key inputs to every business case?  How much money you’ll make, and how much it will cost?  Well, the cold truth is that at this stage, we have no clue on either of these, and we can’t know.

We can’t know how much money we’ll make because that depends hugely on how good the solution turns out to be.  If the team does an excellent job, this could be wildly successful and literally change the course of the company.  On the other hand, the truth is that many product ideas end up making absolutely nothing.  And that’s not an exaggeration for effect.  Literally nothing.  In any case, one of the most critical lessons in product is knowing what we can’t know, and we just can’t know at this stage how much money we’ll make.

Likewise, we have no idea what it will cost to build.  Without knowing the actual solution, this is extremely hard for engineering to predict.  Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old “t-shirt sizing” compromise – just let us know if this is “Small, Medium, Large and Extra Large.”

But company’s really want those prioritized roadmaps, and in order to get one they need some kind of system to rate the ideas, so people play the business case game.

3. An even bigger issue comes next.  Companies get very excited about their roadmaps.   I’ve seen countless roadmaps and the vast majority of them are essentially prioritized lists of features.  Marketing needs this feature for a campaign.  Sales needs this feature for a new customer. Someone wants a PayPal integration.  You get the idea.

But here’s the problem, and it’s maybe the biggest problem of all.  I call this the “two inconvenient truths about product.”

The first truth is that at least half of our ideas are just not going to work.  There are many reasons for an idea to not work out.  The most common is that the customers just aren’t as excited about this idea as we are.  So they choose not to use it.  Sometimes they want to use it, but they try it out and it’s so complicated that it’s simply more trouble than it’s worth, which ends up as the same result – the users don’t choose to use it. Sometimes the issue is that the customers would love it but it turns out to be much more involved to build than we thought, and we decide we simply can’t afford the time and money to actually deliver.

So I promise you that at least half the ideas on your roadmap are not going to deliver what you hope.  By the way, the really good teams assume that at least three quarters of the ideas won’t perform like we hope.

If that’s not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the necessary business value.  We call that “time to money.”

One of the most important things about product that I’ve learned is that there is simply no escaping these truths, no matter how smart you might be.  And I’ve had the good fortune to work with many truly exceptional product teams.  The real difference is how you deal with these truths.

4. Next let’s talk about the role of product in this model.  In fact, we wouldn’t even really call this role product at all.  It’s really a form of project management.  In this model it’s more about gathering requirements and documenting them for engineers.  At this point let me just say that this is 180 degrees away from modern product management.

5. It’s a similar story with the role of design.  It’s way too late in the game to get the real value of design, and mostly what’s being done is what we call the “lipstick on the pig” model.  The damage has already been done, and now we’re just trying to put a coat of paint on the mess.  The UX designers know this is not good, but they try to make it look as nice and consistent as they can.

6. Maybe the biggest missed opportunity in this model, is the fact that engineering gets brought in way too late. We say if you’re just using your engineers to code, you’re only getting about half their value.  The little secret in product is that engineers are typically the best single source of innovation, yet they are not even invited to the party in this process.

7. Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late.  Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods.  What you’re really seeing is Agile for delivery but the rest of the organization and context is anything but agile.

8. This entire process is very project-centric.  The company usually funds projects, staffs projects, and pushes these projects through the organization and finally launches projects.  Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects.  Yes, something was finally released but it doesn’t meet its objectives so what really was the point?  In any case, it’s a serious problem and not close to how we need to build products.

9. The biggest flaw of the old Waterfall process has always been, and remains, that all the risk is at the end.  This means that customer validation happens way too late.

You’ve hopefully heard of Lean Startup methods, which are very much at the heart of the alternative.  The key principle is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature or product only to find out it is not what was needed.  The irony is that many teams believe they’re applying lean principles, yet they follow this basic process I’ve just described.  And then I point out to them that they are actually trying out ideas in one of the the most expensive, slowest ways we know.

10.  Finally, while we’re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead.  We can’t get that time or money back.

To me it’s no surprise that so many companies spend so much time and money and get so little in return.  I warned you this could be depressing.

The good news is that I promise you that the best teams operate nothing like what I’ve just described.

I have written many articles about the various aspects of how the best teams work.  Product Discovery is how we come up with winning solutions to the problems we are attacking.  Discovery is an active and ongoing collaboration between product, user experience design, and engineering. Continuous Discovery and Continuous Delivery happen in parallel.  Features on roadmaps (output) are replaced by business problems to be solved (outcome).  The goal is product/market fit.

If your company is still running this old and long-obsolete process, then hopefully you can shine a light on this and start the transition to the future.  And hopefully you’ll do this before you find yourself disrupted by a startup or competitor that is able to move much faster and more effectively than you can.

The article is from:http://www.svpg.com/product-fail,writed by Marty Cagan.

Behind Every Great Product

When I first decided to start The Silicon Valley Product Group, I had just left eBay and had some very strong opinions about what makes great product teams, and great product cultures, and while there were more than a few important thinkers and leaders on these topics, one area that I felt was under-represented was the role of product management.  So one of the very first things I did was to sit down and write an essay about what I believed about this role.  I titled the paper, “Behind Every Great Product” and it was inspired by the classic Good Product Manager / Bad Product Manager by Ben Horowitz.  The paper proved popular and helped many teams to get a better understanding of just what product was all about.

Now, more than a decade later, I’d like to revisit this topic.  There are three main reasons for this:

First, even though I personally spend a good deal of my time writing and coaching and teaching about product management, there’s little question that there remains considerable confusion about this role.  There are multiple reasons for this but it’s simply too important to continue.

Second, I’ve learned a lot in the years since I first wrote about this.  I’ve had the opportunity to work with many impressive teams and product managers from a broad range of leading tech companies, and this has helped me to get a better sense of the what is essential to the role, and to success.

Third, I argue that the role is now more essential than ever.  I see this role as absolutely critical to success, and very often is the difference between success and failure.

What has not changed is my overarching belief that behind every great product, there is someone, usually someone behind the scenes, working tirelessly, that is playing this critical role  They usually have the title “product manager” but they might be a startup co-founder or the CEO, or they might be in another role on the team and stepped up because they saw the need.  The title is not important; the work they do is.

There are essentially three ways for a product manager to work, and I argue only one of them leads to success:

  1. They can escalate every issue and decision up to the CEO.  In this model, the product manager is really abacklog administrator.  Lots of CEO’s tell me this is the model they’re in and it’s not working.  If you think the product manager job is what’s described in a Certified Scrum Product Owner class, you almost certainly fall into this category.
  2. They can call a meeting with all the stakeholders in the room and then just let them fight it out – this is design by committee and it rarely yields anything beyond mediocrity.  This is very common in large companies, and in this model, the product manager is really a project manager and roadmap administrator.
  3. The product manager can do his or her job.

So my intention here is to show you great examples of this third way of working.

Normally I do this by explaining the critical responsibilities and the necessary character traits and skills, but in this article I will be taking a very different approach.  I want to instead introduce you to real people.

Anyone that’s ever worked in product for any amount of time knows that creating products is never easy, but I selected these particular examples to illustrate the very difficult but essential contribution that comes from a strong product manager.

The products are all iconic, and everyone that reads this will know of every product I describe, but few people know the actual product managers behind these products.  And fewer still know the back stories behind these successful products.

I don’t think these stories have ever been shared publicly before, and they are stories that I believe deserve to be told.

These stories will hopefully show you several examples of product managers doing their job and doing it well.

WORD FOR MAC – Martina Lauchengco

In 1993, Word 6.0 was the biggest release, feature-wise, Microsoft had ever produced up until then.

In addition to all the new features, the team had another very large objective.  Their code base had diverged and it was extremely slow and costly for Microsoft to be implementing Word separately for each platform: Windows, DOS and Mac.  This code convergence effort was supposed to save Microsoft substantial development time, and also – they tried to convince themselves – improve the offering since Word would have the same features on every platform.

It also meant that there was great pressure to get the release out so they could start to gain the efficiencies of a single code base.

At the time, Word for Mac was a relatively small market. It was only $60M vs. Windows which at that point was more than a $1B market.

If you remember back then, Windows machines absolutely dominated, and even the future of Apple was not a sure thing.

However, the Mac community was also very vocal, with passionate fans of their platform, and is also important to note that this community had very little love for Microsoft.

PowerMacs were just hitting the market, which had significantly faster chips and more memory.  Most of the team were using those new computers because the Word 6.0 beta in it’s early days was just too slow on regular Macs.

Of course, most of the Mac user base was not on new PowerMacs, they were on ‘regular’ Macs — hardware upgrade cycles were much slower then.

So when Microsoft released the most “full-featured word processor ever for the Mac” that crawled on their Macs — we’re talking literally two minutes to startup– the community immediately started posting in newsgroups that Microsoft was actually trying to “kill the Mac.”

Hate mail started streaming in from everywhere – including emails directly to Bill Gates who would forward them on to the team with messages like “this is depressing MSFT’s stock price. Fix it.”

Enter Martina Lauchengco, a young product manager recently out of Stanford, whose job it was to help turn this around.

The team quickly learned that while it may be a worthwhile objective to get to a common code base, it’s an empty victory if the product that results is not good.  Moreover, users choose their devices and platforms because they value what’s different, not the same.

From the customer’s point of view, they would rather wait a little longer and have a better platform-specific solution, than simultaneously ship a generic product on all platforms.

The team ended up focusing hard on performance, and taking advantage of what the Mac could do.

They looked at things like when and how to load fonts since Mac users tended to have so many more than Windows users, and ensuring all Mac keyboard shortcuts still worked.

They focused on things like Word Count which is used 10 times a day by every press person to make sure that it was lightning fast, as the press used the feature as their performance barometer. They even made it faster than the feature on Windows.

The result was that in a couple of months, they produced a 6.1 release that was sent to every registered user with an apology letter – signed by Martina – along with a discount coupon for future purchases.

The release succeeded in fixing the perception problems, but more importantly, it genuinely made the version dramatically better for the Macintosh – a product the Mac team could actually be proud of, and what the team felt they should have delivered to market in the first place.

This is a good example of how hard it can be to do the right thing for the customer, often in the face of pretty massive pressures, but that’s exactly what strong product managers figure out how to do.

In subsequent years, not only did Microsoft once again decide to diverge the code base, they completely separated the teams into different buildings and business units, and had them fully embrace all things Mac.  Strategically it was a complete 180.

It’s hard to estimate just how important this was to both Microsoft and to Apple.  Even today, more than 20 years later, many businesses and consumers consider Word and the rest of Office absolutely essential to being able to use their Mac for business and personal use.  What started then became a multi-billion dollar win for both Apple and Microsoft.  There are more than 1 billion Macs and PC’s running Office around the world.

Martina has gone on to have a remarkable career, in both product management and product marketing.  From Microsoft she went on to Netscape, where she was responsible for marketing of the Netscape Browser, and then LoudCloud, and now I’m happy to say she’s been my partner at SVPG for over a decade, and she also teaches marketing at UC Berkeley.

Let me also add that there’s little as powerful as a marketing person that’s also strong at product.  The combination is amazing.

NETFLIX – Kate Arnold

Netflix is one of my all-time favorite products and companies.

But back in 1999, a then very young Netflix based in Los Gatos with less than 20 employees, was on the edge of going bust.  They had a couple experienced co-founders, including the now legendary Reed Hastings, but the problem was that they were stuck at about 300,000 customers.

They were essentially providing the same general pay-per-rental experience that Blockbuster provided, just an online version of this.  There were, as always, some early adopters, and some people lived in places that didn’t have a video store, but in truth there wasn’t much of a reason to do this via the postal service when you could just stop by the local Blockbuster store.  People would rent once, and then quickly forget about the service, and didn’t seem very willing to change.  The team knew that the service wasn’t better enough to get people to change.

Even worse, DVD sales were starting to lag, and a Hollywood backlash further muddied the situation. Then there were challenges with fulfillment logistics, difficulty maintaining DVD quality, and trying to figure out how to do all this in a way that covered costs and generated some cash.

Kate Arnold was the product manager for this small team, and the team knew they needed to do something different.

One of many tests they tried was to move to a subscription service.  Get people to sign up for a month, and offer them unlimited movies.  Would that be perceived as “better enough” to get them to change their media consumption behavior?

The good news was that yes, actually, this really did appeal to people.  A flat monthly fee and all the videos they could consume sounded pretty great.

The bad news is that the team created some real problems for themselves.  No surprise that Netflix customers wanted to rent mostly newly released feature films, yet these were much more expensive for Netflix to stock, and they would need to stock so many copies of these, that they’d very likely run out of money fast.

So the product challenge became how were they going to make sure Netflix customers could watch a set of movies they would love, yet wouldn’t bankrupt the company?

They knew they needed to somehow get customers to want a blend of expensive and less expensive titles.  Necessity being the mother of invention, this is where the queue, the ratings system, and the recommendation engine all came from.   Those were the technology-powered innovations that enabled the new, much more desirable business model.

So the team got to work.  In three month’s time, the team redesigned the site, introducing the queue, the rating system, and the recommendations engine all in support of Netflix being a subscription service.

They also re-wrote the billing system to handle the monthly subscription model (a funny little side story is that they actually launched without this as they had the 30 day free trial month, which bought them the extra time they needed).

With so many moving pieces and interconnected efforts, the daily stand-ups included just about every person in the company.

Between working with the co-founders on the strategy, validating concepts with the users, assessing the analytics, driving features and functionality with the team, and working with finance on the new business model, marketing on acquisition, and the warehouse on fulfillment, you can imagine the workload Kate faced on a daily basis.

Yet the team got the new service up and running and used this to power and grow their business for another 7 years, until they disrupted themselves again by moving aggressively to the streaming model.

Kate would be the first to credit a pretty amazing team, including some exceptional engineers, and the vision and courage of the founders, but I would argue that without a Kate driving for the technology-based solutions that could actually power this business, there’s a good chance Netflix as we know it never would have happened.  This was also a great example of a product manager needing to work across the entire company to come up with not just product solutions but business solutions that work.

One other interesting little aside about early Netflix – when they were struggling for cash early on, they offered to sell themselves to Blockbuster for $50M, and Blockbuster turned them down.  Today Blockbuster is in the dead pool, and Netflix is worth over $40 billion.

Kate is now a product leader at Shutterstock in New York City.


This next example is a favorite of mine.

I’m sure all of you have heard of Google’s AdWords.  You know that this product is what fuels the Google empire.  To be specific, AdWords is currently 16 years old, and last year alone it generated well over $50B in revenue.

What I’m guessing most of you don’t know, however, is just how this industry-defining product actually came to be.  And especially how close this product came to never happening at all.

The year was 2000, and the hardest part about the AdWords project was simply getting agreement that they could work on it.

The core idea had support from Larry Page, but the idea immediately encountered some pretty strong resistance from both the ad sales team, and the engineering team.

Jane Manning was a young engineering manager that was asked to serve as product manager for this effort to try to get it off the dime.

The new sales team, under Omid Kordistani, was off to a strong start selling keywords to large brands and placing the results at the top of the search results, highlighted as an ad, but still very prominent, much in the style that had been done in search results at other companies, including at Netscape where Omid came from.  Sales was nervous that this idea of a self-service advertising platform would diminish the value of what the sales team was trying to sell.

And the engineers, which had been working so hard to provide highly relevant search results, were undersandably very worried that users would be confused and frustrated by ads getting in the way of their search results.

Jane sat down with each of these people to get a deeper understanding of their concerns.  Some were just plain uncomfortable with advertising.  Others were worried about cannibalization.

Once Jane understood the constraints and concerns she was able to advocate for a solution that she believed would address the issues yet enable countless small businesses to get a much more effective advertising solution.  Jane also was able to persuade one of Google’s earliest and most respected engineers, Georges Harik, of the idea’s potential, and he helped to bring along other engineers.

The product solution they ended up with placed the AdWords-generated ads to the side of the search results, so they wouldn’t be confused with the salesperson-sold ads which were displayed on the top of the results.

Also, instead of determining placement based solely on the price paid, they would use a formula that multiplied the price paid per impression with the ad’s performance (click-through-rate) to determine placement, so that the best-performing ads – the ones most likely to be most relevant to users – would rise to the top, and the worst ads would be unlikely to be displayed at all, even if they were sold at a higher price.

This solution clearly differentiated for the sales team, and also ensured quality search results, whether paid or organic.

Jane actually wrote the first spec for AdWords, and worked side by side with the engineers to build and launch.

This is yet another example of how there are always so many good reasons for products not to get built.  In the products that succeed, there is always someone like Jane behind the scenes working to get over each and every one of the objections, be they technical or business or anything else.

Jane took a break to start a family and is now back at Google once again, this time helping out the YouTube team.

BBC MOBILE – Alex Pressland

I have to admit to a soft spot for the BBC.  They’ve been around for nearly 100 years, but they embraced technology and the Internet relatively early.  I’ve seen so many amazing product people have come from the BBC, and many are now all over Europe and beyond.

Back in 2003, a full four years before the debut of the iPhone, a young product manager at the BBC, Alex Pressland, had just finished leading a product effort that enabled the BBC to be one of the first media companies in the world to syndicate content.  Most people at the BBC had no idea why this was important or even desirable, but Alex understood that this enabling technology could be used in new and unanticipated ways to increase reach for the BBC, a major part of the institution’s mission.

Because she understood the potential for IP-based syndicated content technology, Alex started searching for new and useful ways to put this technology to use.  She began by looking at people in the UK that were not being reached by the BBC’s conventional broadcast media (TV’s and Radios in homes and cars).

One such early possibility she found were city center venues that had these large electronic billboard screens that were capable of video.  But she observed that these venues were just playing the same thing you could watch on your television at home, even though the context and audience was very different.

So Alex proposed a series of experiments where she would have editorial teams assemble specific tailored content suitable for specific venues and audiences, and then she would measure the audience reach and engagement.

While this might sound obvious today, at the time this was a very foreign concept to the BBC’s broadcast journalism culture, and there were a long list of obstacles in trying to push the BBC in this direction, not the least of which was editorial and legal.

Editorial wasn’t used to the model where content would be created and then delivered in different contexts.  This gets to the heart of the BBC editorial culture, and required considerable persuasion to show why this was a very good thing for both the BBC and for the audience.

Legal wasn’t used to distribution via IP enabled devices.  Imagine the stack of content licensing agreements that would need to be updated or renegotiated.

The results of Alex’s experiments and early successes gave Alex the confidence to propose to the BBC leadership a new product vision and strategy which she called “BBC Out Of Home.”

It’s important to note that she did this as an individual contributor product manager.

This work ended up fueling a dramatic shift at the BBC from broadcast content to content distribution, and this work dramatically impacted reach, and soon became the basis for BBC’s Mobile efforts.  Today more than 50 million people around the world depend on BBC’s mobile offering every week.

This is not just a story about applying technology to solve problems, but it’s also a story about the power of force of will.  Especially with large and long-established institutions, it is never easy to drive substantial change, but this is exactly what strong product managers figure out how to do.

Alex went on from the BBC to have a terrific career at several tech and media companies, and now runs product for Bauer Xcel Media in New York.

APPLE ITUNES – Camille Hearst

I’d love to introduce you to another very strong product manager, Camille Hearst.

Camille was a product manager on the iTunes team at Apple, and as you might imagine with such a disruptive and ground-breaking product, she experienced and learned a great deal during her formative product years at Apple, especially as she was there during the years moving from the iTunes original DRM-based music, to DRM-free, was critical in helping iTunes to become truly mass market.

Moving beyond early adopters into mass market involved many different efforts, some product, some marketing, and some a blend of the two.  A good example of this blend was the relationship the iTunes team engaged with the American Idol program.

This turned out to be one of the most dramatic and visible – yet challenging product efforts for the iTunes team.

During 2008, American Idol was a cultural icon – watched by more than 25 million people twice a week, with a level of repeat engagement that was largely unrivaled.

Apple saw in this an opportunity to expose an ideal target market to the power of iTunes and digital music.  Not just by selling the music from the contestants featured on the show, but by making iTunes an integral part of consumer’s life.

However, while the potential was substantial, the challenges were significant as well.

The VP of iTunes, Eddy Cue, and others made the business deal, but Camille worked as product manager on many of the integrations to help figure this out.

As just one example, the American Idol program is all about voting, and Apple quickly realized that sales of contestant’s music would very likely be strongly indicative of voting results, and while normally iTunes was designed to show trending music and highlight popular titles, in this case it was important to use extreme care to not influence the voting.

This was obviously critically important to the Idol producers – it would reduce or even eliminate the suspense to learn which contestants would continue to the next week.

The integration also allowed the team to target a very specific persona, and work to drive up engagement with this group.  One of the keys was to make it easy to get to iTunes for those that didn’t yet have the app installed.

By tackling these and countless other challenges head on, Camille and her team were able to come up with technology solutions that complemented the American Idol experience, yet also injected iTunes as a key component of fan’s life.  This contributed to what was in 2014, before the move to streaming, a roughly $20 billion business.

To me this is a great example of how great product managers work to find creative solutions to very difficult problems.

Camille went on to join the YouTube team, and then lead product at London-based Hailo, and now I’m very happy to say that she’s the new CEO of NYC-based startup, Kit.


It is worth noting that so far, all of these product managers demonstrated exceptional results as individual contributor product managers — no Director or VP titles.

For startups or smaller companies, often all it takes is a strong product team with a strong product manager, but in larger companies, in truth it usually takes more than that.  It takes strong product leadership, in the best sense of the word, including providing a compelling product vision and strategy.

One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and successful company.  It’s actually easier in many ways if the company is in serious trouble and they are feeling big pain, because that pain can be used to motivate the change.

But of course great companies want to disrupt themselves before they’re disrupted by others.  The difference between Amazon, Netflix, Google, Facebook and the legions of large but slowly dying companies is usually exactly that, product leadership.

The story I’d like to tell you about here is of a product leader, Lea Hickman.  In the year 2011, Lea was leading product for Adobe’s Creative Suite.

She had helped Adobe to build a very large and successful business for itself – on the order of $2B in annual license revenue – with its desktop–based Creative Suite.

But Lea knew the market was changing, and the company needed to move from the old desktop-centric, annual upgrade model, to a subscription-based model supporting all the devices designers were now using – including tablets and mobile in all their many form factors.

More generally, Lea knew that the upgrade model was pushing the company to take the product in directions that were not good for Adobe customers and not good in the long-term for Adobe either.  But change of this magnitude – revenue from Creative Suite was roughly half of Adobe’s overall $4B in annual revenue – is brutally hard.

Realize that every bone and muscle in the corporate body works to protect that revenue, and so a transition of this magnitude means pushing the company far outside it’s comfort zone – finance, legal, marketing, sales, technology – few in the company would be left untouched.

You can start with the typical concerns:

The finance staff was very worried about the revenue consequences of moving from a license model to a subscription model.

The engineering teams were worried about from moving from a two-year release train model to continuous development and deployment.  Especially while assuring quality.  They were also concerned that responsibility for service availability was now going to be much higher.

There were also big concerns on the sales side, it was expected that this transition would change the way the Creative Suite products were actually sold.  Rather than a large reseller channel, Adobe would now have a direct relationship with their customers.  While many people at Adobe generally looked forward to this aspect, the sales organization knew that this was very risky in that if things didn’t work out well, the channels would probably not be very forgiving.

And don’t underestimate the emotional changes – to both customers and sales staff – of moving from “owning software” to “renting access”.

With over a million customers of the existing Creative Suite, Lea understood the technology adoption curve, and that there would be a segment of the customer base that would strongly resist a change of this magnitude.  Lea understood that it’s not just about whether the new Creative Cloud would be “better,” it would also be different in some meaningful ways, and some people would need more time to digest this change than others.

Realize also that the Creative Suite is, as the name implies, a suite of integration applications – 15 major ones and many smaller utilities.  So this meant that not just one product had to transform, but the full suite needed to transform, which dramatically increased the risk and complexity.

It is any wonder that most companies refuse to tackle something of this magnitude?

Lea knew she had a tough job in front of her and her teams.  She realized that in order for all of these inter-related pieces to be able to move together in parallel, she needed to very clearly articulate a compelling vision of the new whole as greater than the sum of the parts.

Lea worked with Adobe’s then CTO, Kevin Lynch, to put together some very compelling prototypes showing the power of this new foundation, and used this to rally both executives and product teams.

Lea then began a sustained and exhausting campaign to continuously communicate with leaders and stakeholders across the entire company.  To Lea, there was no such thing as over-communication.  A continuous stream of prototypes helped keep people excited about what this new future would bring.

Due to the success of the Creative Cloud – Adobe generated more than $1B in recurring revenue faster than anyone else has – Adobe discontinued new releases of the desktop–based Creative Suite to focus all of their innovation on the new foundation, and today more than 6 million creative professionals subscribe to, and depend on, the Creative Cloud.  Today, thanks in large part to this transition, Adobe has more than tripled the market cap it had before the transition – the company today is worth roughly $50 billion.

It is easy to see how big companies with lots of revenue at risk would hesitate to make the changes they need to not only survive, but thrive.  Lea tackled these concerns and more head on with a clear and compelling vision and strategy, and clear and continuous communication to the many stakeholders.

This is one of the most impressive, nearly super-human, examples I know of a product leader driving massive and meaningful change in a large and established company.

There’s no question in my mind that Adobe would not be where it is today without someone like Lea working tirelessly to push this change through.

Lea has moved from Adobe to leading product for a rapidly rising star in our space, a company and product line many of you know and love, InVision.


Now in every case I just described, each of the product managers went out of their way to emphasize to me just how amazing their team was, and how in no way was the success due to their efforts alone, but hopefully these examples help make clear to you the true and essential contribution of the product manager.

The big points I hope you take away from this are:

1) Product Management is absolutely distinct from the other disciplines.  It’s clearly different than the contribution of the designers, so please let’s stop having all the misguided discussions of overlap between those roles.  It’s also clearly not a project manager.  There is some amount of project management inevitably involved just as there is for all leadership positions, but to characterize this as a project manager is to completely miss the essence of the role.  The role I would argue that the product manager is most similar to is the role of the CEO.  But with the obvious difference that unlike the CEO, nobody reports to the product manager.

2) Like a CEO, the Product Manager must deeply understand all aspects of the business.  The Product Manager needs to ensure a business outcome, not just ensure a product gets defined. This requires a good understanding of the many inter-related parts and constraints of the business – financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user’s experience, and figure out a solution that works for the customers as well as the business. But don’t think this means an MBA is required – actually not one of the impressive product managers I described has an MBA – or that you need to have all these skills yourself; you must simply have a broad understanding of how a product can affect a business, and work with people from your team and across your company to cover everything that’s important.

3) I hoped you noticed that in literally every one of these examples, the winning solutions didn’t come from users or sales; rather great products require an intense collaboration with design and engineering to solve real problems for our users and customers, in ways that meet the needs of your business.  In each of these examples, the users had no idea the solution they fell in love with was actually possible.

4) Like a successful CEO, the successful product manager must be the very best versions of smart, creative andpersistent. By smart I mean using new technologies to reach new audiences or enable new business models. Bycreative, I mean thinking outside the normal product box of features to solve business problems.  And persistent — as in pushing companies way beyond their comfort zone with compelling evidence, constant communication and building bridges across functions in the face of stubborn resistance.  Being a great product manager means having extraordinarygrit.

5) Finally, I hope you can see that true leadership is a big part of what separates the great product people from the merely good ones.  So no matter your title or level, if you aspire to be great, don’t be afraid to lead.

I’ve shown you 6 examples of strong product managers at work as they created products that literally changed the world.

If you want to create ground breaking products at your company, I’m hoping their examples show you just what your job truly is, and what a difference great product management can make to a company’s success.

The article is from:http://svpg.com/behind-every-great-product/

How To Write a Good PRD?

Martin Cagan, Silicon Valley Product Group

The PRD describes the product your company will build. It drives the efforts of the entire product team and the company’s sales, marketing and customer support efforts. It’s hard to come up with a more important, higher leverage piece of work for a company.

The purpose of the product requirements document (PRD) or product spec is to clearly and unambiguously articulate the product’s purpose, features, functionality, and behavior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to provide them the information they need to do their jobs.

If the PRD is done well, it still might not be a successful product, but it is certain that if the PRD is not done well, it is nearly impossible for a good product to result.

The PRD versus the MRD

We draw a distinction here between the product requirements and the market requirements (often referred to as the “MRD”). Put very simply, the market requirements describe the opportunity or the market need, and the product requirements describe a product that addresses that opportunity or need.

The PRD versus the Product Strategy and Roadmap

The product strategy describes a vision, typically between two and five years out, of where you want the product to go, and the product roadmap describes the various steps to get there. The PRD describes a particular product release along that path.


The purpose of this paper is to describe a proven, repeatable process to create a good PRD. The ten steps described here are not easy, but they can help you produce a strong PRD. The amount of time this process takes depends greatly on the size and complexity of your product, and how prepared you are in terms of the knowledge and skills required.

Step 1: Do Your Homework

Your goal with the PRD is to come up with a compelling product. In order to do this, you must do your homework. This means studying your customers, your competitors, and your team’s capabilities, including available technologies.

This begins with customers, users, competitors, industry analysts, your product team, your sales force, marketing, company executives, other employees – anyone that has insight into the problem and possible solutions.

There is much more to the process of preparing, and this is discussed in detail in the paper “Behind Every Great Product” also available from the Silicon Valley Product Group.

Realize also that a significant factor in your ability to convince the team of the eventual success of the product is the degree of confidence you project, and you will be more confident and more convincing if you’ve done your homework well.

Step 2: Define the Product’s Purpose

Every good product starts with a need that it is trying to fill. You must have a clear understanding of that need, and how your product addresses that need.


It is essential that the product manager establish a very clear, concise value proposition that lets her easily communicate to everyone -the product team members, company executives, customers, the sales force-what the point of this product really is.

While this sounds obvious, few products have such a clear value proposition. Consider the “elevator pitch” test. If you had a chance to ride the elevator with the CEO of your company, and she asked what the point of your product was, could you answer that question before the ride is up? If not, you have work to do.

It may be that the product does not have focus; it may be trying to do so many things that nothing clearly stands out. It may be that what you think is the big thing is just not resonating with customers. It could be that your product is trying to solve a non- problem; maybe you have a technology that you’re still trying to find an application for.

The value proposition should also make clear how this product helps deliver on the product strategy. Note that you do not need to talk about every little feature; in terms of a clear value proposition, less is truly more.

The product requirements need to specify exactly what the objectives of this specific product release is, and how they will be measured. The objectives should also be prioritized.

For example, your objectives may be: 1) ease of use, 2) retail price under $100, and 3) compatibility with previous release. You could then go on to elaborate on how you will measure these objectives. For items like a specific retail price, it is straight- forward. For items like “ease of use,” you need to be specific as to what level of usability the product requires. This is typically defined in terms of the target user. Usability engineers can rate the usability of your product for a given type of user. They can also rate the severity of usability issues, and you may specify that there will be no major usability issues.

The key is to be very clear to everyone involved just what success looks like, and to provide the guidance that the product team needs in order to make the necessary trade-offs in design and implementation.

Step 3: Define the User Profiles, Goals and Tasks

Now that you understand what problem you want to solve, the next step begins with an in-depth understanding of the target users and customer. During this step, it is important to work very closely with your product designer.

User Profiles

By this stage, the product manager will have hopefully met with many target customers, and have spent considerable time with first-hand observations and discussions. Now we need to classify the types of users and customers, and to determine who the primary users are.

For example, if you’re building an Internet auction service such as eBay, you know that you have both buyers and sellers, and for each of those you have low-volume/occasional users and high-volume/frequent users. It is not hard to imagine that there are several other less prevalent types of users as well, such as the corporate purchasing agents that may buy items for their company.


What the product manager and designer need to do is first identify the most important constituencies, and then try to characterize them in considerable detail, so that you can use these profiles to guide you in the design of the product. These profiles are sometimes called “personas” and while they should be fictitious, they should be as representative, realistic and plausible as you can make them. The idea is to come up with an archetype which captures the essence of this type of customer.

Here’s an example:

Leon the Power Seller is a 46 year old male that lives in Fresno and runs a small motorcycle parts business. While he does maintain a small shop, almost all of his sales come from eBay, where he sells on average 400 items per month. He sells a wide range of motorcycle related items, but his most popular items are saddle bags for Harley Davidson’s. He owns two big Harley’s himself, and he also drives a 1993 Toyota Pickup. Leon is married and has two teenage sons.

Leon bought his computer just so that he could use eBay, and seldom uses anything except eBay and e-mail. Leon has been selling on eBay for three years now, and has learned what he needed to in order to effectively sell. He has a feedback rating of over 5000, which he takes great pride in. When eBay changes things on the site, especially the selling process, it can be very aggravating for him to learn the differences and change his procedures.

Leon has well-established routines where he lists items to sell on Monday, and most of his auctions end by Friday, and he tries to get the shipments out within a few hours of receiving the payments.

Hopefully this description helps you get to know Leon and understand where he is coming from. As we consider new features, we can ask ourselves what Leon’s response to the feature would likely be, and what we would need to do in order to get him successfully utilizing it.

Narrowing the set of profiles down to just the key ones is essential. Trying to please everyone is futile, and typically ends up pleasing no one, so it is important to try and come up with the few most important and prevalent profiles. Similarly, if you do not try and precisely characterize your target user, you will have this abstract notion and find it difficult to understand how your customers will react. You’ll tend to assume that your customer is more like you than he really is.

User Goals

Once we have identified and characterized our main types of users, we then need to identify what each user’s main goals or objectives are in using this product. This may sound simple, but it can often be challenging to untangle the underlying problem to be solved, when all around you people are telling you essentially the solution they think they want.

Everyone from the CEO to sales reps to engineers to customers are all too happy to “help” you come up with the solution. They’ll tell you that you need to add a button or a shortcut in a particular place, or add a specific feature because a competitor has it, or change the colors because they don’t like it.

The problem with jumping right to the solution is that there are often much better ways of solving a problem that the product manager and designer can come up with, if they are given the time and the freedom to come up with alternative solutions.

The best solution hinges on having a clear understanding of just what problem needs to be solved. The objectives may be different for each user profile, so it is important to be able to look at the objectives in terms of the profile they relate to. It is very possible that the feature being requested addresses a problem that is not one of the objectives of the primary user profiles.


With the user profiles and their associated goals in hand, we can now move on to designing the tasks that help these people accomplish their goals. This is the heart of the product specification process, and is the place where creativity and innovation are to be encouraged and facilitated as much as possible.

Many outstanding products simply solve an existing problem in a new and better way. Sometimes this comes from the application of new technology, but mostly it comes from an insight that leads to a new approach.

For example, TiVo took the old problem of recording TV shows and came up with an entirely new approach that let customers accomplish their objectives much more easily, and established an entirely new category of electronics device.


Notice that we have talked about goals and tasks, but that we have not mentioned features. This is because features should be in support of required tasks that map to customer objectives. You will often find that many features either map to very low priority goals, or are simply extra functionality.

There are good reasons to eliminate any functionality you can in the name of making the required functionality more accessible. Ironically, the fewer features you have, the more powerful your product is often perceived. This is because the less features you have, the more features that your customers will actually discover and use, and the more they can successfully use, the more powerful they will perceive your product. The reason this is so counterintuitive is that most of us are not anything like our target customers, and we are willing to spend far more time exploring features and tolerating complexity than customers not in our industry.

Step 4: Define your Product Principles

By now you should be formulating some detailed ideas on your requirements and the user experience. You will, however, still be faced with countless decisions and trade- offs, and it is important that you have some criteria in which to make the best decisions for your product.

In most teams, each product team member has some ideas in their head in terms of good principles for the product, but rarely do two people have the same ideas, and these differences can lead to unpleasant surprises later.

It is very valuable to try and identify a set of product principles that will guide the entire team throughout the project. These principles will be specific to your domain and your particular project.

As an example, consider TiVo. When the team began on the product effort, the following product principles were established and shared across the team:

It’s entertainment, stupid
It’s TV, stupid
It’s video, damnit
Everything is smooth and gentle No modality or deep hierarchy Respect the viewer’s privacy

It’s a robust appliance, like a TV

These principles impacted the product definition greatly, and in many cases made for a much more difficult implementation, but arguably they are the source of the product’s success.

Similarly, at eBay the mantra was: 1) easy to use; 2) safe; and 3) fun.

You can see how product objectives like these can provide a constant compass for the entire product team in the many decisions they must face during the course of the project.

Step 5: Prototype and Test the Product Concept

This is the stage where you actually come up with your product ideas. This is where you want to be as creative and innovative as possible.

One of the biggest and most common mistakes product teams make is to have far more confidence in their product specifications than they should, and they move forward and think they’ll adjust the product, if necessary, once they get beta feedback. But of course beta is not the time for major changes, and hence no wonder so many first product releases are so far from the mark.

For most products, however, you can do a very significant amount of product validation testing at this stage, using various forms of prototypes.

First, it’s important to consider carefully each of the three forms of testing you will likely need to do:

Feasibility Testing

One immediate question is whether or not the product is going to be possible to build. Your engineers and architects should be very involved in investigating technologies and exploring possible approaches. Some paths will be dead-ends, but hopefully others will prove viable.

What is most important is that if there are obstacles the engineering team considers insurmountable in this product’s timeframe, it is important to know this now rather than discovering this much later in the process.

Usability Testing

Your designers (product designers) will be working very closely with you to come up with ways of presenting the functionality in the product so that the different types of users can figure out how to actually use the product.

Usability testing will often uncover missing product requirements, and also, if done well, identify product requirements that are not as necessary as originally thought. You should plan on multiple iterations before you come up with a successful user experience.

The purpose of the usability prototype is to have something to test on real people, and usability testing is the art and science of getting quality feedback on your product from your target customers. Certainly the product manager and designer will use the prototype and learn a great deal from it, but there is no substitute for putting the prototype in front of actual people from the target customer base.

Product Concept Testing

Finally, it is not enough to know that your product is feasible to build and will be usable, but what really matters is whether or not your product is something users will want to buy – i.e. how much do they like and value what you’re doing? This testing can typically be combined with the usability testing.

For a few small product efforts, simply working your ideas out on paper is sufficient. But for most products, with complex user interactions or new uses of technology, a prototype of some form is absolutely critical in order to assess whether or not the product will meet the product objectives.

The prototype may be a physical device, or it may be a quickly assembled version of a software product. The key is that it needs to be realistic enough that you can test the prototype on actual target customers and they can give you quality feedback.

In the past, there were two major obstacles to prototyping. The lack of good prototyping tools meant that it could take a long time to actually construct the prototype. Another problem was in unaware management not understanding the difference between the implementation of a prototype and the real product, and the teams would get pressured to use the prototype as the basis for the final product, with predictable bad results in the implementation.

Today, there are outstanding prototyping tools that can let engineers or designers rapidly create very functional prototypes that can effectively emulate the future product, to the degree necessary, and form the basis of realistic user testing.

Moreover, most managers today understand that building a simulation and building the actual product are very different – akin to building a scale model of a house, and building the actual home.

It is impossible to emphasize enough how valuable it is to validate your product concept before you go and actually build the product. Once the real engineering begins it becomes very difficult to make significant changes and the costs of the changes rises dramatically.

Step 6: Identify and Question Your Assumptions

Once you think you understand the problem you want to solve, now is the time to start identifying and questioning your assumptions. It is very easy to make assumptions and not even be aware of them. Make sure you don’t specify a candle in the PRD and prevent yourself from getting a light bulb.

Astronomy was originally defined as the study of how the sun and the planets revolve around the earth. Its very definition had an assumption that prevented anyone from getting the right answer.

Step 7: Write It Down

You’ll need to get all this down of course. Most PRD’s are Word documents, but some are Wiki sites, some are PowerPoint decks, and some live on whiteboards. The media and format are far less important than the content. Although what is critical is that the PRD be something that the entire team can easily access, it won’t get lost, and that the PRD needs to be in a form that can be updated throughout the project.

Remember that a conversation is between two people. The PRD communicates to the entire product team.

It is also important to keep in mind that as important as the PRD is, what really matters is the product that gets shipped. Nothing is more important than that. So don’t worry about how pretty your PRD looks or how thick it is. So long as it’s readable and understandable, it is the content that matters.

The PRD is comprised of four major areas.

Product Purpose

Your job is to paint the target. The team needs to know what they are aiming at, and that target needs to be described as clearly as possible. Make sure your description covers:

The problems you want to solve, not the solution

Who is the product for? Companies, Customers, Users Details are great, but the big picture must be clear.

Describe scenarios

Remember that while brainstorming sessions and oral instructions and discussions lead to better written requirements, they will be lost if they don’t get into the PRD.


The body of the product requirements specification will of course be the requirements themselves. The specifics of the requirements will entirely depend on your domain, but regardless of your industry, your product team will benefit from clear, unambiguous requirements that state the need, rather than the solution.

Describe each feature at the level of the interaction design and use cases. You must be very clear what each feature is and what the user experience should be, while leaving as much flexibility to the engineering team as possible.

It is also important to identify which of your requirements are in support of each objective. This is part of the discipline referred to as “requirements traceability” and for mission critical products this is often a formal process. But every product specification can benefit from clearly identifying exactly which requirements support which product objective. If someone decides to cut a requirement, it can be difficult to understand the full impact of this cut. The mapping from requirements to objectives helps make this clear.

Release Criteria

The release criteria are often just hand-waved, but a good PRD puts considerable thought into what the true minimum requirements are, for each of the release criteria, which typically includes:

Performance Scalability



Supportability Localizability


One of the most difficult sections is to describe the timeframe that the product is needed. It is not useful just to list a random date, but rather you should describe the context and motivation for the timeframe, and describe a target window.

You want the entire team to be as motivated as you are to hit that target window, with the right product for the market.

Step 8: Prioritize

Beyond clear requirements, it is important to prioritize and rank-order every one of your requirements. Most product managers, if they prioritize at all, simply indicate whether a requirement is “must-have,” “high-want” or “nice-to-have” (or some comparable classification system).

The classification is important and must not be taken lightly. The product manager should have an extremely high bar for anything flagged as “must-have.” This literally means that the product should not ship if even one of the “must-have” features is not ready. So extreme care should be used for any feature marked “must-have” and these features should map directly to the core value proposition of the product.

The “high-want” features are important, and you do want all of these in the product before shipping if at all possible, but you are not willing to delay the product for these features.

The “nice-to-have” features are useful for the product team to be aware of, even if most of them do not get built until a future release, at least the product can be architected to handle these features, where appropriate, in the future.

While the classification of requirements is necessary, this is not sufficient. Within each prioritization classification it is important to rank-order each requirement, from 1 to n. There are a couple reasons for this.

First, time to market is always a concern, and schedules often slip, and you may well be forced to cut some features in order to get to market. You do not want the product team to implement the easy features first, and end up with several not so important features ready to go, yet customer-critical features on the chopping block.

Second, during the design and implementation phase, the team will learn a great deal as issues arise and are resolved, and it is very possible that you will identify additional critically important features to be added. The prioritization helps you to know what to cut in order to accommodate more important features.

The point is that if the product manager does not prioritize and rank-order the features in terms of their importance in creating a successful product, then other less relevant factors will influence what gets built in what order.

The entire PRD process should be a continuous refinement and sharpening of your thinking. Sharp thinking equals sustainable vision. Fuzzy thinking equals failed product. It is much easier to decide now than in the heat of the battle, and it also helps engineering come up with a development plan. Recognize that time may change the priorities, which is fine, just be sure to make the change in the PRD.

Step 9: Test Completeness

Now that you have a draft of the full PRD, you will need to test the PRD for completeness. Can an engineer get enough understanding of the target in order to get the product there? Can the QA team get enough information to design a test plan and begin writing their test cases?

Once the stakeholders have all reviewed the PRD and identified any areas that need additional details or clarification, and you have addressed these issues, you now have a PRD to build a product from.

Step 10: Managing the Product

During the course of implementing the product, there will be countless questions identified, even with the best of PRD’s. Resolve all questions about requirements by pointing people to the PRD. If it’s not in the PRD, put it in the PRD. Your job is to quickly resolve all the questions and issues, and to record these decisions in the PRD.

If you’ve done your job and kept the PRD accurate, any project reviews that come up should be very easy to prepare for by just selecting from the appropriate sections of the PRD.

Remember that the PRD is a living document, and you should track all features in the PRD through product launch.

Finally, you may find that you need additional topics covered in the PRD. If you believe something additional is required in order to meet your objectives in the PRD then by all means include it.

Wireflows: A UX Deliverable for Workflows and Apps

Summary: Wireflows are a combination of wireframes and flowcharts. They can document workflow and screen designs when there are few pages that change dynamically.


In the UX field, wireframes are a common deliverable to show page-level layout ideas, whereas flowcharts are useful for documenting complex workflows and user tasks. However, despite the fact that both of these deliverables remain in common use among UX professionals, there are situations in which they are suboptimal tools for communicating design ideas, particularly when documenting mobile, desktop, or web apps that don’t have many unique pages, but instead feature a few core pages which change content (or layout) dynamically based on user interaction. In the last few years, an alternative deliverable called wireflow has emerged as a solution to these issues, used to show designs in the context of common user tasks.

Wait a monmen~

A wireframe of a web page conveys layout ideas, content, and page-level design for websites and apps that have few, mostly static pages, but is not as useful in communicating heavily dynamic process flows. 

Wait a monmen~

Flowcharts are used describe both back-end processes and user task flows (as seen in this example).  However, for UX use, they lack the page context — an aspect which strongly impacts the user experience.

Wireflows as a Deliverable for Workflows

Definition: Wireflows are a design-specification format that combines wireframe-style page layout designs  with a simplified flowchart-like way of representing interactions.

Wait a monmen~
This low-fidelity wireflow shows a simple user task. The use of screen designs, rather than abstract flowchart symbols, keeps focus on the product with which users will be interacting. While wireflows can be created in high fidelity for the purposes of communicating detailed design specifications, they are just as useful as lower-fidelity documents to discuss and communicate interaction design and user workflows.

Wireflows emerged as a common practice among teams designing mobile apps, where each step in the flowchart is represented by a wireframe for a full mobile-screen design. Because of the relatively small size of mobile screens, actual page designs (i.e., wireframes) could easily replace abstract symbols in flowcharts. However, wireflows are not merely limited to documenting mobile apps and websites — they can also be used for desktop products, typically by showing a portion of a screen or webpage that changes based on user interactions. Many designs for ecommerce shopping carts and checkout pages are suited to be specified as wireflows.

Why We Need Something New: Flowcharts and Wireframes Don’t Document Complex Apps Well

Usually it’s bad to introduce a new specification format because many stakeholders won’t know how to interpret it. What’s old is usually familiar. However, we do like wireflows because (1) they are easily learnable by those who’ve seen wireframes and flowcharts before, and (2) wireflows have enough advantages to overcome the inertia that otherwise favors familiar formats.

Wireframes are a great way of showing layout, but they don’t describe interaction well, and they are especially poor at documenting the layout of digital products that have a lot of dynamic content, such as mobile apps or webapps. Wireframes are most useful when documenting websites (or other digital products) with many discrete, relatively static pages or screens, where clicking a link or button will typically navigate to a completely different page.

However, many modern webapps and mobile apps have few overall pages, but change the content and layout dynamically through AJAX (or other technologies), based on interactions the user has with the product. They can range from ecommerce products in which selecting facets or filters changes the products shown on the page, to complex creative or technical applications, where the overall layout and information present can vary drastically based on interactions with tools, modes, and other control parameters. In these cases, wireframes don’t capture well the various layout possibilities or the rules for how content changes. In addition, typical wireframes don’t document the important feedback that the system presents to users after they interact with the page. (Feedback that communicates to users that their action has been recognized by the system is critical to a good user experience, and is the first of the 10 usability heuristics.)

Flowcharts, on the other hand are a tool for exhaustively documenting complex workflows and interactions with multiple steps or paths, but typically leave out the context of the interactions and its impact over users. Using flowcharts as the main deliverable to document (and ideate) the interaction design and steps involved in multistep user tasks can lose sight of the information that’s shown contextually on the page and that influences the success of the interaction.

Wireflows Document Interactions

The classic use-case for wireflows is to document the process of a user working through a common task on the product (e.g. “send a direct message to someone in your network” on a social media app). At each step in the workflow a simple wireframe or high fidelity screen mock-up shows the screen available to users.

An arrow is used to indicate the specific UI component where the user takes action (such as a tap on a button, click on a link, and so forth), and points to another wireframe image of what happens as a result of the interaction. The second “node” of that interaction need not be a separate page or screen; rather, it can show the same page with the result of that interaction, such as content that has changed, or feedback that the interface shows as a result of the interaction (e.g., a confirmation popup, a color change, or an error message).  It’s important that the arrows clearly indicate the clickable “hotspots” (or targets) that lead to the next step in the flow, in order to lessen ambiguity in the wireflow. Unambiguously indicating the triggering hotspot is particularly important for complex apps that have multiple actionable targets on a single page.

Wait a monmen~
This simple wireflow shows a sequence of several mobile-app wireframes for a typical user-task flow. In this example, each wireframe corresponds to the same app page, rather than representing different app pages. Each step clearly indicates the hotspots that connect to the next step in the task flow. In addition, the wireflow shows the use of visual feedback in the second step (where the clicked album changes background color to register the tap).

Despite being most frequently used for mobile apps, wireflows are also useful for documenting complex workflows in desktop application and webapps. Since showing a full-screen desktop wireframe for each step in a process can waste a lot of space if most of the screen design stays unchanged at each step, showing only the portion of the screen that changes (such as a dialog box, modal, filters or facets) in each step can be sufficient to document relevant, changing parts of the interface, while still providing enough context.

Wait a monmen~
A simplified high-fidelity desktop wireflow for a configurator webapp demonstrates that not all parts of the screen design must be represented in each step. Due to the larger size of desktop screen designs, showing the full page for each step is not necessary if the majority of the information visible does not change. Using a tactical approach to showing relevant screen designs, one can visualize only the elements that do change due to user input. 

While wireflows excel at showing task flows on apps and dynamic websites where the content or layout on each page changes based on user interactions, they can also be suitable for documenting task flows in traditional static websites. Be cautious, however, about using wireflows to document static desktop sites, as the size of each wireframe image can be large enough to lose the context of the process being documented.

Wireflows for Collaborative Ideation

In addition to being a useful form of communication with project stakeholders and developers, wireflows also work well as a tool for collaboration between team members. Especially in Agile environments, being able to collaborate and communicate well among a crossfunctional team is critical.
Design-workshop sessions can build buy-in and shared understanding among a crossfunctional team; in these parallel-design workshops, team members ideate and write down task flows, the group then discusses options, and the UX person sketches each step in a wireflow style to visualize potential options (and to document ideas that the team agrees on).

In a collaborative environment, wireflows need not be visually polished; these types of discussions are benefitted strongly by using sketching techniques with a whiteboard or paper and pencil to quickly document ideas and focus on the interactions.

Wait a monmen~
Several team members in the UX Deliverables seminar at an NN/g UX Conference use mobile-phone sticky notes, markers, and paper to collaborate on a wireflow in a design workshop. This process can easily work on a whiteboard, or simply using paper and pencil.


Wireflows are an emerging UX deliverable for documenting user workflows and complex interactions for mobile and webapps. They are well suited for representing dynamic changes on one or few pages inside an app, and work less well for capturing flows through a large number of relatively static pages linked together. Wireflows are also useful as a collaboration and ideation technique for teams to think through user workflows and tasks and to ideate screen designs at each step in the process.

(The article is from NN/g by Page Laubheimer).



… much motivations matter. The Zune was crappy because the people at Microsoft don’t really love music or art the way we do. We won because we personally love music. We made the iPod for ourselves, and when you’re doing something for yourself, or your best friend or family, you’re not going to cheese out. If you don’t love something, you’re not going to go the extra mile, work the extra weekend, challenge the status quo as much …


… 动机和热情至关重要。Zune设计不好是因为微软没有像苹果这样有热爱音乐和艺术的工作方式。苹果的胜利是因为员工热爱音乐,他们设计iPod是为了他们自己设计。当你是为自己、挚友、家人设计产品的时候,你才会全心全意、不迷失、不退缩。如果你不热爱这件事,你就不会付出额外的精力、时间,更不会去挑战自我、挑战现状 …


对于设计,诚然我们要考虑商业价值、技术局限、公司架构、市场导向、领导意见…… 但是回归本源,还是得看自己最初对设计的期待和梦想。一样,做你喜欢做的事情。





 1. Fitts’ Law / 菲茨定律(费茨法则)


定律内容:从一个起始位置移动到一个最终目标所需的时间由两个参数来决定,到目标的距离和目标的大小(上图中的 D与 W),用数学公式表达为时间 T = a + b log2(D/W+1)。

它是 1954 年保罗.菲茨首先提出来的,用来预测从任意一点到目标中心位置所需时间的数学模型,在人机交互(HCI)和设计领域的影响却最为广泛和深远。 新的 Windows 8 中由开始菜单到开始屏幕的转变背后也可以看作是该定律的应用。

定律内容:从一个起始位置移动到一个最终目标所需的时间由两个参数来决定,到目标的距离和目标的大小(上图中的 D与 W),用数学公式表达为时间 T = a + b log2(D/W+1)。

它是 1954 年保罗.菲茨首先提出来的,用来预测从任意一点到目标中心位置所需时间的数学模型,在人机交互(HCI)和设计领域的影响却最为广泛和深远。 新的 Windows 8 中由开始菜单到开始屏幕的转变背后也可以看作是该定律的应用。





2. Hick’s Law / 席克定律(希克法则)

定律内容:一个人面临的选择(n)越多,所需要作出决定的时间(T)就越长。用数学公式表达为反应时间 T=a+b log2(n)。在人机交互中界面中选项越多,意味着用户做出决定的时间越长。例如比起 2 个菜单,每个菜单有 5 项,用户会更快得从有 10 项的 1 个菜单中做出选择。


3. 神奇数字 7±2 法则

1956 年乔治米勒对短时记忆能力进行了定量研究,他发现人类头脑最好的状态能记忆含有7(±2)项信息块,在记忆了 5-9 项信息后人类的头脑就开始出错。与席克定律类似,神奇数字 7±2 法则也经常被应用在移动应用交互设计上,如应用的选项卡不会超过 5 个。

4. The Law Of Proximity 接近法则


5. Tesler’s Law 泰思勒定律(复杂性守恒定律)


6. 新乡重夫:防错原则

放错原则认为大部分的意外都是由设计的疏忽,而不是人为操作疏忽。通过改变设计可以把过失降到最低。该原则最初是用于工业管理的,但在交互设计也十分适用。如在硬件设计上的 USB 插槽;而在界面交互设计中也是可以经常看到,如当使用条件没有满足时,常常通过使功能失效来表示(一般按钮会变为灰色无法点击),以避免勿按。


7. Occam’s Razor 奥卡姆剃刀原理(简单有效原理)

这个原理被称为“如无必要,勿增实体”,即如有两个功能相等的设计,那么选择最简单的。在极客公开课?走进 UC 中 UC 浏览器产品经理苏剑南在”UC 浏览器 For Android 产品设计思考“演讲中也有讲到该原理的应用,”如果 UC 手机浏览器要发布第一个版本 UC 1.0,你会选择哪五个功能?‘’

为了遵守神奇的数字 7 法则本篇就只介绍到这里了,如果你还有兴趣自己去找找其他的定律法则,如与费茨定律接近的 Steering Law转向定律、Gutenberg Diagram古登堡图法则以及雷打不动到哪哪适用的帕累托定律(80/20 原则)、三等分原则等。

最后想说的是虽然这些法则定律被很多人认定为标准,很多人也记得 Alan Cooper 说过的那句名言,但从实际出发这些法则定了起到的只是参考或启发作为,作为交互设计人员千万不能照本宣科,因为只有亲自做过后才会深有体会。