Twitter’s VP of Product, Validation, Storytelling and Sherlock Holmes

Michael Sippey at 1871

Today I attended a CEC Talk featuring Michael Sippey the VP of Product at Twitter. The talk was pretty fun so I thought I share some of the content I found interesting.

Why Learn About Product Management

As a designer the product role and philosophy of a company is really important to the work I do. Most designers will have to work with a product manager, owner, director, etc. at some point in their career. In many organizations designers work in the product department and even have titles such as product designer. Obviously the field of product designers call themeselves by that title, but I’ve also seen a trend of visual and UI designer migrating to that title.

As as a designer who specializes in interaction and experience design, I have often find myself helping to discover and define large aspects of a product. This is why I think it’s important to learn more about how people who specialize in product management think. What I learned from Sippey is that at Twitter the product management process is really similar to the interaction and user experience design process, both which actually borrow heavily from the scientific methods. (Admitted and purposefully way less rigorous than science.)

Notes From Sippey’s Talk

Market Validation

He gave an interesting story of when (prior to Twitter) he tried to pitch a product to his boss. His boss told him that for his idea to get resourced he would need to do some market validation. The approach he told us about is very similar to the Lean startup validation concepts. Basically find the easiest way to see if there is interest in the product. At the time, prior to Google Adwords where you could track interest, he was told that he should attempt to get pitch meetings with 30 customers. If you can’t get 30 current customers to listen to your pitch then obviously they won’t be interested in using the product. If you can successfully reel in 30 customers than you need to work on you presentation to share your vision of the product with the customers.

He didn’t go into much detail about what to present externally, but he did mention a few tips for after the pitch. Ask the customers in the room if they think the idea is a base hit or a home run. After this explain to the customers in the room that if they had $100 they could invest in product features or offerings how would they spend it. This will let you know if what they really want is for you to fix bugs in your current product or if they really do desire a new feature or product. I like both of these ideas, although I don’t think I would ask them directly in the room. That would basically create a focus group environment which is wrought with issues. I do think these questions would be great as a part of a follow-up survey. (The survey could be conducted in the room after the presentation.)

Tell Me a Story

When pitching product ideas internally he recommends providing the following:

  1. Have a vision and clearly explain it
  2. Clearly layout the strategy
  3. Define the specific problem you’re solving
  4. Express who you are solving it for
  5. Describe how you can measure success

This is very similar to how design is pitched. I generally start in a different order though:

  1. Who are we designing for (or with)
  2. Describe the insights that were found from observing, interviewing or analyzing the “user”
  3. Express the strategic approach of the design concepts
  4. Describe a vision where the design concept lives. Even if early in the design process, provide the context in which the design would live and be used, give some details of the design form and content.
  5. Define what’s required to do further validation

Newton, Feynman, Sherlock Holmes, and (almost) Aristotle

What does a mathematician, physicist, fictional detective and philosopher have in common? The scientific method of coarse! They all used it a bit differently and perhaps a bit inaccurately, but ultimately their goal was to find validation through methodology. Sippey (and many others) recommend using the basic framework of the scientific method to help guide your product decision making.

  1. Question
  2. Hypothesize
  3. Experiment
  4. Observe & Record
  5. Analyze
  6. Share Results

Sippey strongly encourages that sharing results should be the number one priority. In order for people in the organization to learn and move forward results need to be communicated.

I think this approach is really good for incremental product and design experimentation. It not great for creating innovative leaps. It will still work for the validation process, but sometimes ideas and vision need to be invested in quite a bit before they can be validated. Ideas can take many forms and vision can be express in many ways. Complex problems tend to have very ambiguous factors which is what makes them complex. To find a solution(s) takes a lot of iteration and research before a vision or idea can be properly validated. On the other hand a form or expression of a solution can generally be easily validated or debunked, but just because one expression doesn’t work doesn’t mean the vision or idea should be abandoned. I think this is where design thinking’s iterative methodology fits in nicely.


Listening to Sippey talk today really did reinforced how much overlap there is between designers and product folks. It’s key for all of us to spend more time learning how other roles work. This is why many designers learn how to code, we spend so much time working with developers it makes the process so much easier if we can speak a bit of their language and even implement “the details” ourselves. I hope more of us designers can start inviting our product managers, developers, business intelligence analysts, and other product influences to learn more about design methodologies and how they can benefit from being t-shaped.

Add Your Comments

Your email is never published nor shared.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <ol> <ul> <li> <strong>