Help Me Help You: Getting Great Consumer Insights

by Tiffany Niver

 

We don’t know what we want. Decades of psychology, economics, and sociology research has shown that people are quite poor at predicting what they want, how it will make them feel, and the long-term implications of gratification. This makes ground-breaking product innovations all the more complicated as understanding users becomes an exercise of mind-reading…and then some. Knowing the limitations of consumer insights and going into the process with a healthy sense of skepticism can empower creativity in coming up with the most impactful tests and analyses. The key to getting great consumer information is focusing on obtaining as much behavioral insight as possible, while following the lean start-up principle of “maximizing learning for unit of time and effort expended.”

Many entrepreneurs and researchers follow a fairly standard path of gaining customer insights.

• Baselining Through Consumer Self-Reporting: Before any development or investment begins, they rely on surveys, focus groups, and interviews to learn about markets and consumers. These self-reported methods can be extremely useful in understanding purchasing behaviors, usage patterns, pain points, and customer needs. Oftentimes consumers can accurately articulate their frustrations and desires, and these become cheap and easy ways to get validation for business ideas. However, consumers base their recommendations or experiences on the status quo and thus have difficulty imagining a world which is much different from their current situation. Thus for incremental changes to existing products, these techniques can be extremely useful, but for dramatic deviations from the status quo, the reliability of these methodologies decreases.
• Piecemeal / Feature Testing: Once entrepreneurs have their concept finalized and some features or interactions available, they complete smoke tests and feature tests to see how consumers interact with their concept or feature. These tests can further analyze one or two hypotheses and can be helpful in understanding how much appetite there is for a concept or how users react to pieces of a product. A major limitation is that the consumer (and the entrepreneur) still doesn’t know how the set of features or hypotheses will interact together.
• Full Product Testing / Behavioral Insights: Much further down the road, a full product is available and a consumer can test every aspect of the experience. At this point, entrepreneurs have access to a tremendous amount of information provided by every click or every piece of feedback that the consumer gives. This helps get into the mind of the consumer and is usually the first time where an entrepreneur can get the actions rather than just the words or intention of consumers.

Each phase of consumer feedback is extremely important, but - with the limitations of self-reported information - oftentimes behavioral feedback is the ideal methodology. A key obstacle, however, is that this necessitates actually having something for users to test which requires time and money. The “holy grail” of consumer testing would be a low-development behavioral test where one could get the benefits of usage data without the costs. While this is clearly difficult to do, entrepreneurs should push themselves to be as creative as possible with testing by doing things like:

1. Using existing data on consumer behavior more thoroughly (i.e. Wings using Facebook data to launch a product based on consumer behavior)
2. Creating quantitative data / observing consumers in similar environments (i.e. Cake Financial observing consumers on Quicken, on their trading platforms, or doing research)
3. Continuing to build the most minimally viable products to test consumer behavior (i.e. Rent the Runway putting together trunk shows)

A key learning I’ve come away from my own experiences and LTV thus far is that actions speak louder than words and until you have something in front of the consumer, you don’t know exactly how they will react. So get out there and do some behavioral testing!!

Read More

Creating Culture Through Prototype Development

by Aunim Hossain

Baller.  You’ve spent months running around, talking to everyone you know (or don’t know), attending conferences, scouring the online job resources…all with the goal of building your dream team that will take this from a great idea to a company that will change the world.  And you rocked it.  You have the team you need: one product manager (you), three developers with front-end and back-end skills, and one artist/UI guru. 

You feel like you’ve arrived.  You say to yourself, “now, it’s all about getting it done, but that should be pretty simple with the team of ninjas I assembled, right?”  But this is where many promising founders stumble.  Even with the right team in place, success is not guaranteed.  While there are many variables that determine success, one of the most important variables that founders can control (and often don’t) is building the right culture. 

Culture is created through the processes that founders and the team members put in place to complete tasks.  As those tasks are completed, the team figures out which processes work and which should be revised.  When a particular process becomes second nature for the team to complete a certain task, it has effectively become culture.  As founders, it is our job to guide the creation of the best processes and make sure that the processes that become culture are the right ones for the team. 

In this post, I hope to start a list of the best processes that have come to define the culture of our team.  In this first try, I’ll talk about our experiences with communication and time management.

So tell me what you want, what you really really want… 

Oh those Spice Girls were sages.  And it makes sense that they knew what they were talking about when it comes to communication: they were a startup had to manage a team of five divas.  In our startup, with my own team of seven divas, we thought that putting everyone in a room together would ensure strong levels of communication.  But several major problems from spec misunderstandings, to code deployment issues, to artist delays continued to creep into our work hours.  In the end, we figured out that the fundamental issue was a lack of communication.  Although we’re still working a lot of these issues out, here are a few processes that we’ve put in place that will hopefully create a culture of over-communication within our team:

Create a Backlog of Detailed Specs:  As the product person, my ultimate goal is to take the idea that is trapped in my head and make it real.  But because I need help from other people to make this happen, my first task is to take the idea that is in my head and put it in the heads of everyone on the team.  Now before we figure out how to really do mind-melds, we have to rely on specs.  So make your specs as detailed as possible.  Don’t assume that your team will fill in the details, because where there is uncertainty, there is room for miscommunication.  Also, if there is a feature that is important in the future, don’t wait to write the spec.  It is critical to build a long backlog of specs so that the team knows where the product is going and they can build functionality to be flexible and accommodate what’s coming next. 

Daily Scrums:  Although we started this practice on our first day and most teams use this process, I know that it has been instrumental to our team’s cohesiveness.  Functionally, a Scrum for us is a daily team meeting that lasts only 30 minutes (everyone is standing up so that it’s clear that the meeting will be short).  One by one, each person has the floor and talks about what they worked on yesterday, what they are working on today, and any questions that they have for other people.  After setting it up, our team started using it for functions that I had not thought about before I saw it happening.  For example, we use it as our daily deliverable when I am able to see where we are at on the code and art.  Other team members use it as a way to make sure they are on the right track when solving a problem.  Other team members use it as a way to look at the big picture of what we’re doing and get pumped up about our progress. 

Other Practices: We set up skype chat for each of the team members so that communication lasts all day.  Often, there is a tremendous amount of collaboration that happens in a seemingly silent office.  We also set up a wiki that documents, in a central place, the components of each of our Sprints, and what everyone is responsible for.  It is a constantly evolving document that is primarily updated by me, but it is very helpful in understanding what people are working on in the long term and where there may be gaps. 

In the end, as we set up all of these processes, the most important lesson that I have learned is that great communication starts at the top.  Unless you demonstrate that you are communicating yourself, your team members will likely not communicate either.  For example, if you say that everyone on the team should email whenever they have questions, it will probably take several emails from you before the team buys in and takes it from there. 

Time is on my side, yes it is…

In this section, we learn from the Rolling Stones.  It’s an ageless, optimistic message that runs in contrast to the typical entrepreneur’s mindset, that stresses impatience (and the cornerstone of lean methodology).  Now, I definitely agree with this mindset: we can’t just sit on our ideas while someone is out there hustling with a similar one; we can’t just keep working on prototypes without getting them out to users who can teach us; we can’t go back and spend days cleaning up code when there is so much to be done with our existing code base.  I agree with all of that.  What I don’t agree with, however, is the mentality that time is the enemy.  As a founder, it is important to frame time as our friend.

This is an important lesson for me because I was always under the impression that, by setting stretch deadlines, I could get more out of me and more out of the team.  By framing our work as a race against time, we could encourage hard work and higher performance.  However, this view has only served to make us look at the short-term goals and lose track of the long-term needs of the company.  With time as the enemy, we introduced all-nighters, hardcoding, a lack of flexibility, low morale, and stress into our processes.  By doing so, we ended up being more behind in reaching our goals.  Thus, these processes below ensure that we all look at time as our friend in product development:

Balance Speed vs. Scalability of the Code: When your team is “costing out” features (determining how much development time, cost, and art is needed for a feature), it is important to tease out the real tradeoffs between getting done on time and the corners that will need to be cut.  For the product person, it makes sense to include the entire wish list in the spec, but you should be aware of what tasks are vital and which can be pushed.  As an engineer, it is vital that you understand which shortcuts can be used now to meet this deadline, and which shortcuts don’t make sense because it’ll take more time to revisit three deadlines down the line.  It’s very hard for everyone to understand these tradeoffs, especially early on in the development cycle. 

Therefore, I believe that it is important to set easy deadlines with several days of cushion for the first few sprints.  This will give the team the flexibility to focus on building scalable code early and establish understandings of the tradeoffs that they will have to make later.  Technical debt is inevitable, but it should be avoided early because it compounds.  As the team learns more about how they work together and about where the product is going, the deadlines can become tighter.  But early on, focus on the scalability vs. speed.

Establish Best Practices…before you need them:  When you believe that time is on your side, you can spend some time thinking about what processes you will likely need in the future and build to them now.  By doing so, the team can learn how to use them before they are really in a jam.  On our team, we set up bug tracking through Bugzilla, subversion hosting and deployment through Beanstalk, and other systems before we had bugs and multiple developers in the code.  By doing so, we were able to create a plan for scaling so that when we hired people, they could get ramped up quickly.  Indeed, if you can take the time to look ahead and plan for the future, you can save a lot of time today.

Now, there are only a few lessons that I have learned as we tried to create a culture through the prototype development process.  In your comments, please feel free to comment on these processes, but also feel free add your own best practices.  I’m looking forward to reading them.

Read More

Why Yin Needs Yang: Product Managers and Engineers

by Iris Guerra and Lorin Pace

The principles that apply to well-developed product manager – engineer relationships are also applicable to early-stage exploration.  Fred Wilson talks about this dichotomy in The Yin and Yang of Product and Engineering, characterizing the relationship as follows: “the product person sets the overall requirements, specs them, focuses on the UI and UX and manages the process. The engineering person builds the product or manages the team that builds the product, or both.” In a venture that is exploring an idea and looking for proof of concept, this relationship translated into the product person making the engineer think about the product features and value proposition by posing questions that testers or first adopters would likely ask, such as: What is this? How does it work? Why is this useful? Why should I try it? How do I use it?  

Responding to these questions allows the team not only to test the concept, but also to frame the idea in a way that makes it easier to explain and sell to potential customers, partners, employees and investors. On the other hand, not having a clear answer for any of these inquiries indicates the team needs to focus on refining the vision in that particular dimension. In either case, it’s critical to ask such questions at the ideation phase. Having a yin – yang balance of product and engineer roles is a way to ensure these issues are well-developed and addressed at an early stage, avoiding problems later in the process.

Read More

If the Customer is King, the Product Manager is Regent

On Not Bending to Customers' Whims


by Katharine Nevins (blog: http://katharinenevins.posterous.com/)


The goal for any startup (or product manager for that matter) is to build a product which customers need and love.  It’s easy to call yourself or your company customer-centric, but actually doing what is best for customers isn’t always straightforward or intuitive.  There are two main reasons why listening to customers doesn’t inevitably lead to good products.  Firstly, not all customers need or want the same thing.  Secondly, customers often do a poor job of knowing or articulating what they want.  Fortunately, both of these problems are addressable.

For most products, different customers will have different needs.   Power users have different needs from new users: Sarah Dillard points out that Quora’s integration of feature requests from its power users have led to a bewildering experience for new users.  Different user segments may also have conflicting needs.  Natasha Prasad gives a great example of the trouble Digg had appealing to its original “geek” segment while trying to attract more mainstream users.  While working on Quickbooks, I saw a constant tension between adding features for power users or new verticals  vs. upholding our reputation for ease-of-use.   Creating new SKUs for power users (e.g. Premier edition) and verticals (e.g. non-profit edition) helped, but maintaining too many separate versions of a product is not ideal for a lean startup.

The most elegant “lean startup” solution I’ve seen to this problem is to use partnerships and open APIs to extend functionality.  Eventbrite, for example, allows third-party developers to build features or niche solutions such as an event check-in app through its apps showcase.  Eventbrite remains lean by allocating its resources to only the highest-impact new features.  Its customers all benefit by getting a simple but powerful product with an option to add only the extras they really need.

This API-based  approach has famously worked for products such as Salesforce (with the AppExchange) and Apple’s iPad/Pod/Phone (with the App Store).  Social products relying on user-generated content can make this approach work as well.  Apps built by Twitter’s developer community allow different customer types to use Twitter as a marketing platform, a news feed, or a social tool as they prefer.  The (potential) challenge for newer companies such as Foursquare and Quora is that they’ve already built their products for an early-adopting niche.  Now, they need to remove or change the early adopters’ favorite features so the product can be used by Normals.  Is there an elegant way to roll out a “Krunk-badge”-free version of Foursquare to soccer moms while keeping the existing, bar-hopping user base happy?  I’m not sure.   Thoughts?

Misleading or nonexistent customer input is even more unintuitive to deal with than conflicting customer feedback is.  Even within a specific customer segment, customers often can’t or won’t tell you what they really need.  Customers often ask for features they wouldn’t actually use.  Watching focus groups talk about their personal finances from my side of the one-way glass at Intuit, it seemed to me that their well-intentioned requests for better personal finance tools would in no way change their actual spending behavior, and therefore the tools would probably not be used even if we built them well.  Other users don’t ask for features they would use.  Prof. Piskorski’s research suggests that one of Facebook’s biggest uses is by men looking at pictures of women they don’t know.  However, these men probably wouldn’t have asked Facebook’s product managers for a better way to check out girls, and it’s possible they wouldn’t admit to this behavior if asked by a researcher or product manager.  Finally, customers are limited in the solutions they think to ask for.  A customer who didn’t know about email wouldn’t ask for a BlackBerry.

Separating what the customer needs/ wants to do (the job) from how the customer will do it (the product) is the key to addressing this issue.  The customer often knows what job he wants to do.  If he can’t articulate it well, then observing his behavior as IDEO does will help the product manager figure it out.  The goal of the product manager or startup founder is not to tell the customer what to do, but to identify how to help the customer do something he wants to do anyway.  Customer statements of how they want to achieve their goals should be taken with a grain of salt.  In the year 2001, I would have asked for a faster Napster when what I really wanted was Pandora (though I didn’t know it yet).  To identify the best how (product), the product manager should come up with a few alternatives to test on users, then use their input to decide.  In this way, she can create a product even better than what users would have asked for themselves.  

Read More

Creating Mountains of Technical Debt in Lean Startups

by Joris Poort

Lean methodology values employing minimal effort to get to the next milestone.  Lean principles have a short-term focus to test hypotheses, which is quite rational considering that once a hypothesis is disproven you haven’t wasted any time in further wasted effort.  Customer development methodologies also encourage similar principles, ensuring a deep understanding of the customer and the market before embarking on the development of an expensive product that nobody wants to buy.  These lean principles and culture will work great in optimizing the path to get initial traction, but could wreak havoc on further development of the product causing avoidable risks down the line.

Creating technical debt through minimizing waste

Specifically in software development, lean product development can result in significant technical debt.  To be sure, technical debt refers to the costs associated with hasty software development resulting in neglecting architecture, incomplete testing, and incomplete documentation.  Subsequently, once a product has accumulated technical debt, further development work contains interest payments on this debt in the form of building on code that still needs further work to truly be complete.  In the future, this debt can be paid off through rewriting the code in the right architecture as intended, completing all the testing necessary, and completing documentation.  Acquiring technical debt, in fact, is often a direct result from applying lean principles, since activities that do not add immediate value to achieving the next milestone in a product release should be considered waste. 

Vicious cycles of technical debt

The issue of technical debt accumulation is further compounded by the fact that once technical debt has been accumulated, cost-benefit analysis will often show that paying off the debt creates value in the long term, but destroys value in the short term – thus a bad decision if you are choosing the most efficient lean path to the next milestone.  This vicious cycle of technical debt accumulation can result in large amounts of increasing debt overhang, causing significant amounts of interest payments that significantly hinder and potentially stall further development.  The vicious technical debt cycle is analogous to taking out increasingly higher rate credit cards to pay off previous debt accumulated; you keep buying yourself a short term lifeline at an increasingly higher long term penalty.

Symptoms of technical debt are hard to identify

While a great developer with intricate knowledge of the code can provide a decent estimate of technical debt, this debt is often hidden and unknown to higher management.  The symptoms of technical debt are very hard to identify.  A development cycle with large technical debt interest payments results in development delays that often can’t be attributed to anything in specific, typically unfairly blamed on the miscalculation of estimated development timelines.  Subsequent decisions made based on a misunderstanding of technical debt situations can lead a startup astray – resulting in anything from slight misallocation of resources to cutting off potentially profitable product lines.  In situations where technical debt is the root cause of development delays, misinterpretation by management can result in severely misguided decisions.

How to really stay lean

Using lean methodology as a guide, product development timelines and decisions should be made balancing the optimal short term solutions with an awareness of the long term consequences.  There is nothing wrong with accumulating technical debt, in fact similar to financial situations, acquiring some debt to attain certain milestones more quickly can certainly result in value creation.  But be mindful of the longer term risks involved and addicting qualities of debt, a vicious cycle of technical debt can create a house of cards that will sooner or later come crashing down.  Early investments in good software architecture, testing, and documentation create higher cost and minimal benefit in the short term, but can pay huge dividends in the long term.

Some tips on how to avoid acquiring mountains of technical debt in a lean startup:

• Ensure management has a clear understanding of the level of technical debt
• Balance the short term needs for technical debt creation, with the longer term benefits of paying it off
• Understand the large shadow cast on software development by architecture, testing, and documentation

ADDENDUM

Response to comment below by Tristan

Tristan,

Thanks for the feedback – let me further explain and clarify how I’m thinking about the topic, hopefully the following addresses your concerns.

Also, while I am an MBA student, in full disclosure – I have two engineering degrees and worked in technical product development in entrepreneurial environments for over four years.

You correctly assert that there are many unknowns in the early stages of a startup.  At the extreme, when everything is unknown, you are right in stating that the best architecture cannot be known.  Lean startups are however all about focus on turning these unknowns into known facts as quickly as possible as you iterate from customer feedback.  Thus, I would argue that the unknowns should be quickly diminishing over time, especially in the early stages of a very lean hypothesis driven startup.  Secondly, many of the unknowns in startups are in fact “known unknowns” vs. “unknown unknowns”.  Known unknowns are ones that can be prepared for (unlike unknown unknowns) and taken into account in the architecture to ensure flexibility as necessary.  Lastly, even in the case where you have many unknowns there is still a big difference between “quick and dirty” coding to get the job done and code that has been well architected upon which it is easy to build and iterate further.  Regardless of a complete understanding of where the product is going, there are still significant architectural features that can be made within the code to allow for faster feature creation and iterative improvement.

With respect to testing and documentation, in both cases the threshold for what is required to do a good job is significantly beyond that required to develop code that works.  If there is significant pressure to release early and often, which there should be in a lean startup, the necessity of doing a decent job on testing and documentation the first time around is low while the pressure to release is very high.  As hypotheses become validated and the code base becomes more mature, the technical debt created in obsolete code is naturally eliminated, but the technical debt in the code base needs to be evaluated to be paid off to increase developer efficiency going forward.

My perception is that complete code rewrites are much more uncommon than you assert, and the decision to completely rewrite 2.0 could spell complete disaster for startups.  The list of things that can go wrong is extensive:  Chad Fowler states rewrites take longer, are harder, and more failure-prone than expected.  Jamie Zawinski’s experience should give you pause before rewriting.  David Hansson says its experience rarely a good idea and often ends in failure.  Joel Spolsky says its the single worst strategic mistake that any software company can make.  Steve Blank says its startup suicide.  I rest my case.

I am not proposing development of a “perfect architecture” like you mention, rather a more reasonable balanced approach to consider both the short term and long term impact of decisions to pay off the technical debt or carry it forward.  The more conversations management has with the engineering team, the better these issues can be surfaced and resolved.  Technical people certainly should have the best insight on measuring the quantity of debt, but I disagree with the notion that the decision on what to do should lie purely in the hands of the technical team.  The amount of technical debt carried forward at key decision points concerns all areas of the organization and the final decision to pay it off or carry it forward should be made taking all stakeholders into account at the higher management level, in the case of early stage startups, probably the CEO.

Best,

Joris

Read More

Speaking Nerd: Communicating With Developers

by Josh Sandberg

There’s been quite a bit of debate on this blog (e.g., here and here) about whether or not it’s important for business folk to learn programming. Personally, I think that gaining a least a basic understanding of how things are architected “under the hood” will pay dividends throughout your startup career. But either way – and especially if you don’t have any programming experience yourself – you’ll need to be communicating your vision with your development team, and knowing how to do this effectively will (a) rapidly increase your iteration speed, (b) help you realize your actual vision, as opposed to some sub-par version of it, and (c) make your developers much happier.

Step one is good mockups. There are several tools out there to help with this process, the best known of which is Balsamiq. They’ll make your sketches prettier and save you some time drawing rectangles, as well as give you handy examples of some common ways to display and interact with data (user interface elements). At the end of the day it doesn’t really matter how pretty your specs are, but do invest time into thinking about what information you want to display on each page (and in each element) and how best to convey it: this should be one of the key parts of your product vision. Entire startups can be built out of thinking of better ways to interact of data – for a recent example, just take a look at Hipmunk. Don’t just throw everything you think you might need in and plan to pull out bits later: simplicity takes a lot more work, but is crucial to a good user experience.

Step two is good specs. This means thinking through every one of the actions that a user can take on each page of the site, and how the logic should flow. The hard (but crucial!) part is making sure you consider and address every possibility: what happens if a user clicks on this button when she is logged in? What about if she isn’t logged in? What if he hasn’t set up a particular option yet? If the user’s entering data, what filters are necessary to determine if the data is valid, and what do you do if it’s not? In my experience, one of the big differentiators between mediocre specs and great ones is the coverage they have of these edge cases. Force yourself to think of every possible scenario, and put down everything in excruciating detail. You may think many of these are trivial, but whoever’s implementing your spec is either (a) going to have to figure out how to deal with these situations himself, which slows down development and can lead to very inconsistent design choices, or (b) is going to miss or ignore a possible use case, which leads to bugs and poor user experiences down the road.  It’s also important to make sure you’re specific about what to do in every case, down to the level of what data to display/collect/store/modify, what dialog to show the user, and where to take the user next. Otherwise what seems so obvious to you can often get lost in translation, and you’ll wonder how the final output could be so different from your initial vision.

Finally, before the coding ever begins, make sure you have a high-level discussion with your lead developer(s) about the consequences of your design decisions. Make sure you understand what parts are difficult (and why), and what’s easy. For the stuff that’s hard, brainstorm if there’s an alternative solution that eliminates much of the complexity, or if there’s some way to test the utility of the feature before implementation (maybe a smoke test). Agree on a mutual prioritization and timeline. And once development does begin, make sure you’re available for rapid feedback & get your hands on iterations as early as possible.

For others with experience in product design / management / interfacing with developers: what are the techniques & tips you have found particularly useful?

Read More

The Making of a Spec-zilla

by Vlad Loktev

So you’ve got an idea for the next kickass software product. You’ve done your homework. You talked to a gazillion people, did three months of market research, got your parents’ advice, and bought a timeshare on the islands of Fiji in anticipation of your soon to be great fortune. You are so excited you also went out and spent 50 bucks on brand new business cards. Well…before you start handing these out to everyone you see, and hiring a 20 person engineering team, you should probably slow down a little and write out your idea on paper.

Most people refer to a detailed idea on paper as a “product spec.” In a nutshell, a spec tells the reader what the product should do. The purpose of a spec is to effectively communicate every nook and cranny of your idea to everybody around you - your friends, co-founders, developers, and most importantly yourself. I found that oftentimes every product detail is very clear in my head, but once I sit down to actually write it all out, I start running into all sorts of issues that I didn’t think of before.

Here are some tips I’ve found useful that I wanted to share in case they save somebody else some time and potential aggravation:

1.     Quick summary. Always start your spec with a few sentence summary about your vision for the product. The goal of this part is to communicate your high-level vision quickly. Don’t get lost in the details. Anybody on your team should be able to get a general sense of the vision after reading these few sentences. Writing a short summary will also help you focus on what’s really important. If you can’t write two sentence about your vision, then you probably haven’t through the idea through yet.

2.     List functionality. In bullet form, write down everything you want the software to do. “Share images with other users; Comment on people’s images; Message other users.” Once again, it helps to be succinct in this stage. This section should give everyone a snapshot of the functionality that will be built.

3.     Explain the value. Write out why each feature listed in #2 should be included in the product. What value does it add? What problem does it solve? What evidence do you have this feature is valuable/correct solution? Answering questions such as these accomplishes two things: a) it forces you to think through each feature carefully and to begin understanding what the most important/necessary features are; b) it helps show your team the value of what they are building.. there is nothing worse than developing without being excited about the impact you can make. Show your team that your vision is worth staying up at night for!

4.     Create user profiles. Time for some role play! List and describe all of the “types” of users who will interact with your product - Logged in user, Logged out user, First-time user, etc. Explain each user’s characteristics.

5.     Create navigation flow. This is where you write out how all of the functionality interacts throughout the product. I found it super useful to create separate navigation flow for each user profile. Explain how a Logged in user can go from page to page, etc.

6.     Exhaust use cases. Here is where the real challenge comes in. You need to clearly explain how each piece of functionality should behave in every scenario of the world you can think of. If done well, this section will probably be the longest part of your spec. Pretend you are an obnoxious user trying to point out every flaw in the product. What happens if you type really long messages? One character comments? Really long comments? Attach really large pictures? Cycle through the UI buttons in random order? Don’t forget to have some fun with this one. Try to break the product.

Congrats! You’ve made it through the first six steps in one piece. That’s a huge accomplishment. In the process, you probably bashed your keyboard a few times, pissed off a few friends, and neglected to exercise… but all is well in the world – you are almost done!

7.     Prioritize. Your team won’t be able to take a stab at everything in your spec all at once. After doing all that work, you probably have a good sense of what the necessary components of your idea are. Tell your team! Prioritize each feature and use case (I typically prioritize everything into three categories – High, Medium, Low… but you should try to be a lot more creative than me).

8.     Use pictures. I can’t stress this enough. Show, don’t tell. Use pictures (mocks) as often as you can. Being able to see what you are talking about will help out your team a ton. Your mocks don’t have to be pretty… just get a basic layout together. It’s very likely that you’ll be changing the look and feel of your product continuously through A/B testing anyway.. so if you are strapped for time, it’s better to devote more attention to flushing out all the use cases rather than trying to perfect something that will change shortly anyway.

9.     Moderate. When everything is said and done, think about the person you’ll be handing off the spec to. Do you really want him or her to read through a 25 page word document? It’s totally demoralizing! Have some pity on your teammates. It’s also likely that he’ll skip through important sections of the spec. At first, hand over the initial 5 sections… these should be enough to get his heart pumping. Then hand over the rest of the spec in pieces. Keep in mind that the structure of your specs may and should change overtime. There is no one style that works for everyone. Experiment and see what works for your team. Bon voyage!

Read More

Product Leaders as Poets and Librarians

by Rob Go, cofounder of NextView Ventures, HBS MBA '07, and coauthor of a case on OPOWER and note on product management that we'll study in LTV. This post is republished with permission from Rob's blog.

I’ve been writing a case on Opower for Harvard Business School which is centered around the role of the product leader.  Opower is a wonderful example of a company with a complicated product, that is scaling quickly, and brought in an experienced outside executive to lead the product organization.  It turns out, that product leader is my friend and former colleague Ben Foster, who worked with me at Ebay many moons ago.

To understand the rationale and impact of an experienced product executive in a scaling startup, you’ll have to read the case J  But one concept that came up in our interviews is the profile of a really great product leader.  The challenge of this role is that it requires the combination of two very different baskets of skills that are not often embodied in a single person. 

Tom Eisenmann at HBS brought up an analogy he picked up from Drew Houston at DropBox, and I thought it was really helpful in illustrating this dilemma.  The idea is that great product leaders have attributes of both a POET and a LIBRARIAN.

POETs are product visionaries.  They often are deeply in tune with the problems they are solving, and are instinctive about how to build products that succeed.  They are extremely creative and are willing to trust their own gut over the reported needs of customers who might think they need feature x, y, or z.  They often think many moves ahead, and see the implications of individuals feature in the evolution of the holistic product experience.  I’ve also observed that poets can sometimes pivot more easily as they search for the right feature mix, design, and marketing message that really resonates with their users.  Usually, one of the founders of the company is a product poet.  Otherwise, the company would have never come into existence.  And sometimes, the poet can lead the product team for a very long time, but other times, you need a second basket of skills to really make the company successful.

LIBRARIANs are organized and systematic. They are data driven in their decision-making, and work to design teams and processes that can reliably ship quality code in line with the priorities of the company.  As the product and engineering team scales, a Librarian can figure out how to create a structure that can coordinate the efforts of many while maintaining the creativity and information flow between teams. A librarian is also obsessed with the details and data.  They understand how small things can make a huge impact, and understand how to unlock the value of data to optimize a user flow or build a beautiful new feature. 

Most product leaders I know tend to fall into one camp or the other more naturally, but a successful company needs both over the course of its life.  When I was at Ebay, I’d argue that we were way too heavy on librarians over time and short on poets.  But I think much of Zynga’s success stems from the fact that they have terrific librarians optimizing every detail of their games.  Tumblr is let by a Poet (hope David doesn’t take offense) and you can see it in the creativity of the product and some of the non-obvious moves the company has made over the years (like not having a native commenting system).

Generally, I think the skills of a Librarian can be taught, especially for quantitatively oriented folks.  Not so sure about the skills of a Poet, I think it’s much much harder to develop. 

By the way, the case is for Launching Technology Ventures a new course taught by Tom Eisenmann. It’s a terrific course, and Tom posted some great online resources for the concepts that he is teaching.  I’ve reblogged it once, but it’s so great, I need to share it again here. 

Read More