2 years, 8 months ago 0
Posted in: Post

I attended the Startup Lessons Learned Conference (http://www.sllconf.com/) in SF on May 23rd. Hosted by Eric Ries—the man who coined the term, “lean startup,”—it was an interesting, information-packed event. While none of the info was life-changing there were quite a few “oh-yeah’s”—stuff that I had done, or knew, but saw restated in a way that helped emphasize its importance.

As Mitch Kapor put it, “Our capacity for self-delusion is unlimited. Lean methodology can help compensate for this basic human fallibility.”

As an example, one thing that impressed me was how customer development methodology enabled companies with “non-groundbreaking” ideas to achieve (some modicum of) success. Dave Binetti founded a company called, Votizen, which was conceived of as a social lobbying platform for registered voters. His initial idea was to build a Facebook for Politics, postulating that people want a stronger voice in politics and community affairs, and hosting a donation engine (the business model) that would allow Votizen to take a cut of funds donated. Really—it doesn’t strike me as the world’s most compelling business proposition. It’s very unclear that figuring out how to donate to causes, is a hard problem that needs solving.

Over the course of 18 months, Votizen did 4+ different pivots, moving to a campaign management tool (pseudo-enterprise) and finally to a tool they described as Ad Words for Activism—a tool that allowed individuals to email representatives (and causes to email
individuals?). They charge for every email, and this business model (although arguably no more compelling than the original)—has been a money-maker from day one.

18 months, $120 k spent, 4 different pivots and numerous optimizations. They found a profitable business model. Nice work.

The other interesting aspect to this success is that we often think we have to “swing for the trees,” with our business ideas in order to be successful. That is–you can’t start something unless and until you have a “billion dollar concept.” Many of the companies presenting at the conference had very modest ideas that they had exploited to good measure—and proved they could be profitable. So, you’ve got to get on base before you can score a run.

One of the more inspiring presentations at Startup Lessons Learned, came from Brad Smith—the CEO of Intuit. Brad described how Intuit has institutionalized innovation; how they germinate it and nurture it.

According to Brad, the two most dangerous words in business are, sounds good.” “A culture of analysis and planning is a culture of
politics.”

While I’m not sure that I completely agree with that sentiment, his larger point is that when big companies become big, they tend to lose their entrepreneurial spirit. And, you have to make a conscious effort to ensure that doesn’t happen.

At Intuit, they break their product efforts into 3 categories:

1) Horizon 1, Existing businesses: These are large businesses like Quicken, which account for the bulk of company revenue. They generally have developed their own metrics, are growing slowly and run themselves like the mature businesses that they are. Their job is to become more efficient and to find and exploit incremental market opportunities.

2) Horizon 2: Emerging businesses: These are business that have come out of incubation, have gained market traction and are growing rapidly. These have the promise of becoming Horizon 1 businesses and their job is to find the product and customer combinations that drive this growth.

3) Horizon 3, Intuit Labs: Intuit Labs is like an entrepreneur’s fund. It’s composed of “2 pizza” teams (no more than 6 people). The ideas these team work on come from their “unstructured time,” which is time that Intuit gives people for exploration and ideation. Their charter is to “go fast,” and come up with a prototype in 6 weeks or less.

The businesses that Intuit Labs pursues are startup businesses. Most will not be successful—but, some will turn into Horizon 1 & 2 opportunities, and somewill make a material impact to existing businesses. At Startup Lessons Learned, Brad Smith cited “Live Community Chat” in TurboTax as one of the Lab’s ideas. Community Chat let’s members of theCommunity pose questions and get answers from people who are using TurboTax. Who would want to use that? It turns out that 40% of questions were answered more accurately by the Community. The engagement drove customer satisfaction higher.

Intuit SnapTax is another product that Labs incubated. The team originally planned to allow customers to scan their W2 and 1099 forms and to automatically assemble a tax form from the results of those scans. After some brainstorming and customer research (i.e. most people don’t have scanners), the team decided to create an iPhone app than let people scan their W2’s and create a 1040EZ tax form which could then be automatically submitted to the IRS. Who needs to pay money to create a 1040EZ? Lots of people want to at $19.99. The product has gotten an incredible response and is growing rapidly.

The moral of Brad Smith’s story was that innovation and entrepreneurship at big companies is possible—but, it doesn’t happen on its own. Intuit invests 60% of their resources in Horizon 1 businesses, 30% in Horizon 2 and 10% in Horizon 3. They try to keep things fast, fun and innovative. They host “Entrepreneur Days,” to give employees the opportunity to get mentoring on ideas and business models. And, they do over 10,000 hours of customer visits a year (including Brad) to ensure they’re in touch with the market.

Having worked for big and small companies, it was inspiring to see how the CEO of a major software company helps preserve a small company spirit, and how that strategy helps drive top-line growth. As Brad said:

It’s not the answers you have it’s the questions you ask.” Set up an environment of experimentation, and find out what delights your customers and grows your business.


2 years, 10 months ago 0
Posted in: Post

People who have worked on a variety of teams or for a variety of companies have—no doubt—noticed that high-functioning teams are are 2 – 10 times more productive than those who aren’t. And, in fact, when you’re working on a team that is in synch, it’s fun. It does feels like a well-tuned machine, where deliverables are happening on schedule; issues are identified in advance and are dealt with; and product features are happenin’.

So, why is it that some teams hit this groove, and others just don’t? More importantly, what can you do to turn a team that’s just getting by, into a high performing team? Why is this easier in a small team, or a startup?
In First, Break All the Rules (a great book on management), the Gallup organization found that a person’s answers to five questions were essentially predictors of their desire to stay at a company. They are:

  1. Do I know what is expected of me at work?
  2. Do I have the materials and equipment I need to do my work right?
  3. Do I have the opportunity to do what I do best every day?
  4. Does my supervisor or someone at work seem to care about me as a person?
  5. At work, do my opinions seem to count?

First, Break All the Rules is not a book that offers the standard rear-view mirror approach to management. It’s by a research organization that pries apart some fundamental truths about people, managers and organizations via surveys, statistical analysis and good insights—analytics, not platitudes. It suggests a number of good methodologies for hiring and working with individuals.

But, one thing that it doesn’t really deal with is how you create processes that help to positively affect these questions/issues. In other words, it provides a good backdrop for managers to think about issues like setting work goals and about how personally they engage with teammates. However, it doesn’t suggest ways to run a group in a fashion that promotes these elements (and maybe that’s just because it’s difficult to generalize process solutions across industries).

For example, what does it mean to have the opportunity to do what I do best every day? Or, how about—at work do my opinions seem to count?

There is no doubt that holding people responsible for achievable objectives, and guiding them through the steps needed to help reach those objectives is essential. Knowing what is expected of you is really the cornerstone of job satisfaction and productivity. If you don’t have clarity, nothing else will follow.

But the question still stands—how do you build a team that has a rhythm? What kind of organizational framework or tools encourage engagement, communication and dedication to a shared goal?

If you want a shared goal, you need a shared vision. And to achieve a shared vision, you have to get people to put skin in the game, which is most effectively done by making everyone participate in the process of helping to develop that vision.

This is consistent with the idea (shown below) that the path to any ideal solution is almost never a straight line. It involves iteration and feedback from team members (and hopefully, customers) can help a designer or product manager craft a superior solution. So, making team members a part of the solution results in greater buy-in and a higher-quality outcome.

Source: Design Criticism and the Creative Process by Cassie McDaniel

There are a number of things that my team does to help accomplish this:

  1. Be very planful in setting Sprint goals at our Sprint planning meetings. These goals are the most important deliverables for the Sprint. We explicitly review progress on each of the goals during standup. This keeps everyone focused; helps us make the right trade-offs when (important) distractions come up; and helps us fine-tune the handoffs between PM, Dev and Test.
  2. Ensure that Specs are delivered before the beginning of Development. This requires that they be started (usually) several Sprints before Dev is expected to work on them.
  3. Go thru a process of progressive refinement in feature conceptualization and development
    • Problems: Define the problems we are trying to solve and the subset of users we expect to address with those. These are the “pillars” of the release, and are really define the big buckets of functionality we want to provide (meet, get feedback)
    • Experiences: Identify the “experiences” that address the problems identified above. In this context, an “experience” is a the way the problem might be solved, with some suggestion as to how the user interacts with the program to accomplish it (meet, get feedback)
    • Features: Once the experiences have been defined, come up with a number of different mock-ups to help team members understand what a feature might mean from a UX point-of-view. I typically use Balsamiq, Viso or PowerPoint (UX toolkit) to create these. This helps puts some flesh on how the feature might look and work (meet, get feedback)
    • Detailed Investigation: For the feature implementation that’s been chosen, we usually do quite a few more mockups, and occasionally a Dev investigation into some of the complexities and technical issues surrounding the feature. Some of the technical realizations lead to additional functionality and/or improved UX in the final feature.
    • Specs: When we understand what it is and how it’s (generally) going to work, then we dive into the details.

This general framework is shown, below:

An example of the way that we scripted a particular “experience” (rich content widgets) is:

And, the way that is articulated in a mock-up is:

Despite the meetings and discussions, this kind of process is fast. There isn’t a lot of formal spec writing that goes on until the very end. And, a lot of thinking happens up-front.

Probably the most valuable reason for following this kind of a process is it engages the rest of the team in helping you figure out what you should build. This not only results in everyone having “skin in the game,” but it invariably means that the solution you come up with is going to be higher (usually much higher) quality, as it enjoys the collective perspectives of a team’s worth of people instead of one individual.

And, circling back to my initial point–engaging people in a robust process helps them have the opportunity to do what they do best everyday. It helps them understand that their opinions count. And, at the end of the day, it helps you build a more functional and productive team.

Some additional, interesting reading:
Lean UX at work

Lean UX for startups (start around slide 14)


2 years, 11 months ago 0
Posted in: Post

I recently attended a talk by Tom Rideout at a PSSIGCHI (Puget Sound special interest group on computer-human interaction), entitled,  ”It’s not all about the user – tailoring experience design to your business.” I thought it was a somewhat provocative title for user-experience related presentation. Given that product strategy and product management is increasingly customer-centric, and that UX design is a key element of that, I was wondering—“what’s up?”

The key premise/take-away of Tom’s presentation was that the “customer(s)” and the user may, in fact, be different people. And, designing for the user without understanding the customer is a recipe for failure.

In the late 80’s, HP developed a GUI called, New Wave, which was an object-oriented graphical desktop environment and office productivity tool for PCs running early versions of Microsoft Windows. New Wave allegedly made working with files and data/objects easier. Tom’s group worked extensively with end users to craft the system, and ensure it was easy to use, provided appropriate functionality, etc.

They pitched New Wave to a company that was looking for a platform their agents could use to run their company software and book customer reservations. The IT manager who was tasked with evaluating programs and platforms asked whether his agents would be able to access and use other programs in addition to the reservation system. “Of course,” was the answer. “Why would we want to do that,” he replied. “We want our reservation agents making reservations. Not playing Solitaire.”

The point that Tom was making—which I see frequently in the context of product management (and less so in the arena of UX design)—is the idea that there may be a wide variety of people involved in a purchase decision. There is the economic buyer, there are gatekeepers and other decision makers who may play a role in evaluation or purchase.

This is bread-and-butter stuff for most Marketers, but not intuitive for many experience designers. And, the key take-away for those in UX was: Every required participant in the business system is a candidate for the experience design discipline.

I take this to mean that if an IT manager is a gatekeeper in the purchase decision for a specific product—then the designers who are tasked with designing the product need to understand their concerns and to specifically address them in order to earn the sale.

To understand this issue, answer these questions:

  • Who must benefit for the product to succeed?
  • Who choses it among alternatives?
  • Who pays for it?
  • Whose experience needs to change to deliver the value:
    • Throughout the business system?
    • What do they need to be a willing participant?
  • What experiences will be attributed to our company and brand? Which will have the biggest impact on the business?

You can create an awesome end user experience, but have a complete business failure unless you understand, and design for all the people involved in the decision-making process.

It just goes to reinforce that old, annoying saying that’s trotted out by every other sales person I’ve ever met:

Everyone is in Sales

Yep, ‘guess so.

 


2 years, 11 months ago 0
Posted in: Post

When anyone talks about the job of product management (or program management), they tend to emphasize the importance of getting out of the office and talking with customers. You have to understand the customer and feel their pain. And, the quintessential quote one hears is “The answers aren’t found in the office.”

I’m neither foolish nor inexperienced enough to argue with that one. But, what is equally important, and what I don’t hear people talking about is the importance of spending time studying your own product in excruciating detail and becoming expert enough to be absolutely convinced you know exactly what features need to go in the next version.

Getting out of the office is only half the story…

There is no magic formula for determining the next feature you should put into your product. You need to have a product backlog, sure. And, within one of your backlog categories, it’s not hard to come up with a pretty decent prioritization and costing of those items. But—what to do next isn’t a question that calculus will answer. You need to look at a bunch of different issues:

  • The competitive landscape – what features does the competition have that you will need to match/exceed
  • Actual or assumed customer segmentation—which features are for what audience, and will that move the dial?
  • Company strategic priorities
  • Innovative ideas that can help position the product in a noteworthy fashion
  • What incremental features can be added to help current customers be more productive?
  • What features are consistent with architectural changes you need to make?
  • What features, if grouped together, help tell an easy-to-understandable story?
  • What features will generate excitement and buzz?
  • When does the release need to ship?


An MRD, or Marketing Requirements Document, is a standard (outside of Microsoft) document that lays out the strategy for a specific product release. Typically prepared by a product manager, the MRD is designed (like most PM documents) to drive team alignment and focus. Most MRDs have 3 general sections:

  • Market Opportunity: What is the business opportunity? How does the market segment, and what are the needs and peculiarities of each segment? Who are the competitors and what aretheir SWOT? What trends are driving change? The Market Opportunity section of the MRD is an evolutionary one, meaning that each subsequent version will build upon the foundation of the previous release.
  • Marketing Requirements: Marketing requirements are the specific problems that a given release is trying to solve. These problems are informed by your product backlog—but don’t come directly out of it. Typically, these problems are associated with specific audience segments (e.g. for a web authoring tool, “Help users add rich content widgets to their web pages,” would be associated with a hobbyist or prosumer customers who haven’t developed their own library of standard HTML/JS widgets). As an aid to developing Market Requirements for a
    product release, it’s critical to have a robust product backlog that’s categorized in a fashion that reflects real-world customer processes, like an affinity tree (more on that in a future post).
  • Go-to-Market Strategy and Tactics: Typically developed by Product Marketing in conjunction with Sales, the go-to-market plan lays out the promotional and marketing/advertising strategy for the release. It includes goodies like the product positioning, channel strategy, pricing strategy, key features statements, etc. This section will often contain Sales projections (which are typically “hoped for” Sales projections).

When I say—Be the MRD—it reflects my belief that the abundance of customer and market information you’ve collected will not itself point you in any particular direction (and—it rhymes). As always, data itself is just data. And, typically, two different people will look at the same data sets and come to the polar opposite conclusions. So—YOU (as PM)—need to be the tool that integrates all the disparate piece of market, customer and other information and comes up with the right direction.

From my experience, it’s not enough for you to visit customers, do research and go to trade shows. As I said earlier—you need to work with your product enough so that you Grok it and are absolutely convinced you know exactly what features need to go in the next version.

Then, you have to be flexible enough to put aside your opinions in an instant based on customer input or market evidence.

You can’t come up with the right answer unless you have a well-developed point of view (it’s one of those knowing the path, walking the path kinds of things). You can’t make an informed assessment without understanding (some of) your customer’s pain. You can’t feel it, second-hand. You’ve got to become a customer.

So, dive in and do a bunch of projects with your product, and understand firsthand what some of the problems, issues and inefficiencies are. Only then will you be capable of putting yourself in other customers’ shoes and understanding their pain. It’s the process of developing empathy.

As an example, when I was working on Photoshop 2 (when dinosaurs roamed the earth), there were hundreds of feature suggestions we had collected from customers and our own observations. Photoshop was an unusual product in that it was so general-purpose that it was used by an incredible range of different customers, from graphic designers to prepress to software developers to illustrators and so on. So, it would have been easy to peanut-butter features across a wide set of user scenarios.

We decided to focus on 2 scenarios/objectives:

  • Build bridges/synergy with other Adobe products to increase the likelihood that Photoshop customers would also buy Illustrator, and that Illustrator customers would also purchase Photoshop. This also helped distinguish us from the competition, which didn’t have equivalent leverage. For these customers, we added support for Adobe Type Manager, built the Illustrator rasterizer into Photoshop (so, line art could be incorporated into bitmap designs), and engineered a Photoshop version of the Illustrator pen tool (for creating
    precise, vector masks).
  • Attract an emerging customer segment—prepress. Prepress houses are establishments that create color separations from photos and artwork to so they can be printed. While we had recognized this group could use Photoshop, we were completely blown away by how quickly they adopted it. Existing prepress houses used Photoshop to supplement their existing Crossfield and Scitex equipment. Service bureaus used Photoshop (exclusively) to enter the color separation market. For these customers we added a CMYK editing mode (a significant “first”), and the ability to create duotone/tritone/quadtone images.


This release had the effect of increasing Photoshop revenue like a step function. The revenue ramp suddenly took a big jump, and then continued to ramp at an increasing rate. This is symptomatic of a product that suddenly appeals to new segments (or increases its appeal to existing segments).

The customer data alone couldn’t tell us this was the right strategy. There were at least a dozen different customer segments, lots of compelling and sensible customer requests, and—frankly—a paucity of high-quality research info. But, I strongly feel that my own use of Photoshop (I helped illustrate the first Photoshop poster; wrote several articles on it; edited the tutorial guide; created interface mockups, etc), played a major role in informing the decision-making process and acted as a sieve for the customer information.

Was every feature choice perfect? Probably not. But, the strategy—which informed the feature decisions—was spot-on. And the act of integrating all of the elements of the MRD (market opportunity, customer problems, go-to-market strategy) into my brain (and those of the product team—Mark, Tom, John & Russell), made it a dynamite release.