• About Me

Christine's Corner

~ Musings about products & the valley

Christine's Corner

Monthly Archives: October 2014

Three Legged Stool

23 Thursday Oct 2014

Posted by Christine in design, eng, PM

≈ Leave a comment

To create a successful product, three functions must come together: engineering, design and product, much like a three-legged stool.  If one function is broken, you are unlikely to have a great product.

three-legged-stool

For this partnership to work, each function has its role.  It’s the Product person’s job to articulate the “why”, and Design and Engineering to figure out the “what” and “how”, respectively.  Some tension is natural.  My philosophy is that some heated debate is healthy.  No one should take things personally, since debates push more clear thinking and help flesh ideas out.

In terms of Product’s “why’s”, it’s the Product person’s job to answer a few questions:

  • Why are we building this product?
  • Who are we targeting?
  • What is the market landscape?  Who are the players in this space?

It’s Design’s role to articulate the “what”.

  • What’s the overall user experience? In the case of a mobile app, this ranges from the onboarding experience to navigation to rewards to sharing with others.
  • Visual design – from color palette, font selections, etc.

It’s Engineering’s role on “how” is to determine the technology stack that can accomplish said product.  Engineering should be primarily concerned with performance, scalability, and flexibility (tweaking features as a product finds product-market fit).

I mentioned three functions above, not three people.  In some cases, it’s necessary for someone to take on multiple roles.  This is often the case for new products, when someone has a new idea and wants to prototype a product, or even launch an MVP.

I’ve worked in a number of startups and bigger corporations that don’t have a designer on staff. I take on the role of an interaction designer and then seek out the support of a visual designer.  That’s never ideal but is necessary to move projects forward.

While I did not explicitly include a QA lead in the paradigm, this role is often combined with engineering.  Bringing a QA lead into the discussion early is always helpful as he or she often helps identify failure use cases based on experience with other products.

Regardless of how many people you have to get started on a project, having a strong Product person who can articulate a clear vision on “why” we are building this product is crucial.  Without one or someone to take on that role, you may not be building the right product to begin with.

 

Advertisement

Share this:

  • Twitter
  • Facebook
  • Email

Like this:

Like Loading...

Saying No Is Hard But Necessary

21 Tuesday Oct 2014

Posted by Christine in PM

≈ Leave a comment

People want to be liked.  So naturally you want to say “yes” to people who asked.

As a product manager, having the confidence to say no to a feature is a necessity. Building a product is all about focus.  Focus on your target audience and strive for simplicity.

Kevin Systrom, founder of Instagram, began with a complicated location-based iPhone app, named Burbn, that let users checkin and post pictures of meet-ups with friends. Kevin and his colleague Mike Krieger used analytics to determine how their customers were using Burbn and learned that people were using the photo-sharing, not the main check-in, features.  They decided to focus on their photo-sharing infrastructure and eliminated almost everything else.

This is a case of saying “no” after a product has been built.   Emotionally, it’s really hard to kill features.  But you have to consider all your investment as “sunk cost” once you learn that something is not working.

 

Share this:

  • Twitter
  • Facebook
  • Email

Like this:

Like Loading...

Books About Silicon Valley Founders

21 Tuesday Oct 2014

Posted by Christine in books, founders

≈ Leave a comment

I love listening to audiobooks on my daily commute.  It’s challenging to find free blocks of time to enjoy books on weeknights and weekends, which made my 40-minute commute each way a blessing in disguise.

I love “reading” about biographies or memories of Silicon Vally startup founders.  Here are my favorite ones:

51S2iJN3DYL._SL80_51j1P236E3L._SL80_  61zCMnP6nZL._SL80_51ysl-BDgGL._SL80_  51ULBoVSTcL._SL80_

  • Steve Jobsby Walter Issacson
  • The Hard Thing About Hard Things: Building a Business When There Are No Easy Answersby Ben Horowitz
  • Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal by Nick Bilton
  • Delivering Happiness by Tony Hsieh
  • Rework by Jason Fried, David Heinemeier Hansson
  • The Everything Store: Jeff Bezos and the Age of Amazon by Brad Stone
  • Creativity, Inc: Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull and Amy Wallace

Other books I am reading or in my Audible library are:

  • The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution by Walter Isaacson
  • Zero to One by Peter Thiel, Blake Masters
  • The Launch Pad by Randall Stross

I am always looking for book recommendations….Please share yours.

 

Share this:

  • Twitter
  • Facebook
  • Email

Like this:

Like Loading...

Three Levers In Product Development

21 Tuesday Oct 2014

Posted by Christine in PM

≈ Leave a comment

As a product manager at startups, I am often put in charge of overseeing engineering and delivery schedules.  Along with the number of hats I wear, I am fortunately afforded more levers that PMs typically don’t have.

Over the years, I’ve come to realize that there are 3 main levers in building and launching products.

leversFeatures

  • For a new product, decide what is the minimum set of features to include to determine there is a product-market fit.
  • For an existing product, assess the incremental set of features to meet immediate customer needs and differentiate from competition.

In both cases, it’s important to be “ruthless” in cutting out features that are not crucial.  In my last job at Reverb, I was tasked to launch the iPhone app as a follow-on release to the iPad version already in the market.  It’s both a new product (in terms of device/form factor) and an existing product (server-side functionality remained mostly the same).  After considering iPhone usage patterns, I decided to cut out an edit-heavy feature (creating and editing a collection of articles).  That significantly reduced the project scope and simplified the user experience.

Quality

At launch, I always make sure that there are no showstoppers/crashes (P1) and critical bugs (P2), those include illogical user flow, typos, functionality not working as described).  Assessing the criticality of each bug is mainly the role of a product owner (using Scrum speak), supported by a QA colleague.

Schedule

Most Internet software companies are adopting Agile.  At end of each sprint, there should be a releasable candidate (theoretically), but it’s not always the case.  While I respect the philosophy behind Agile, you really need to build in time for integration testing and device compatibility testing, particularly for mobile apps and responsive websites.

With all that said, holding quality constant, you are really down to two levers – features and schedule.

  • Schedule – it’s not in the spirit of Agile/Scrum to set a release date in advance, but it’s often necessitates by market timing (e.g. consumer electronics targeting Q4 in retail channel, promotion in time for Dads & Grads in June, etc).  In the case when a schedule is inflexible, push back on new feature requests and actively work to manage the scope of committed features.
  • Features – when a feature is crucial and must be included in the next release, the schedule becomes a secondary consideration.  When iOS 8/iPhone 6 were released, we ran into issues with an early release of Xcode 6 in terms of auto layout.  It then took several days before we resolved the auto layout issues to support both iOS 7 and 8 devices.  I held up the release and “ignored” our original launch schedule.

In summary, you have 3 levers, but cannot be prescriptive about all 3 at once.

I would love to hear what other considerations or levers you see in terms of building and shipping products.

Share this:

  • Twitter
  • Facebook
  • Email

Like this:

Like Loading...

Intuition Vs. Data-Driven

17 Friday Oct 2014

Posted by Christine in PM

≈ Leave a comment

Tags

intuition, PM

Much like the decade-long debate on nature vs. nurture, there has been much discussion on whether product management should be intuition vs. data-driven.  I’ve often been asked what type of product manager I am – the intuitive (aka. fly by the seat of my pants) or data driven (aka. don’t do anything unless the data justifies it) type.

Product management requires a healthy mix of product intuition and data-driven decision making.  You have to find a balance.  Product intuition about what to build, whether you have product-market fit, whether this feature is part of MVP is all forward-looking.  Where as data-driven decision making, e.g. whether to deprecate a feature because of its low usage or does the A/B test result show a statistical significant improvement, is backward-looking.

Ingenuity and intuition are necessary to come up with differentiating features that make your product stand out in the marketplace.  Looking at data closely helps you make informed decisions about an existing product.

My first job out of Kellogg’s MBA program was a product role in the Marketing group at Netflix.  My job involved running pricing tests, redesigning the free trial funnel, and shepherding a number of non-member site changes.  I ran dozens of A/B tests and analyzed results before making a site change recommendation.  In that role, I made decisions primarily based on data.  Because pricing and user acquisition were so closely tied to revenues, my job involved a lot more data analysis rather than defining new features.

Fast-forwarding nearly a decade, I was in charge of redesigning the TechCrunch redesign in 2012.  To begin, I re-imagined how the tech blog could be organized, how I could bring videos much closer to the rest of the site, and how the river (of stories) could be less monotonous, and so on.  I had the charter to keep the engagement up (retain or increase all page views), as well as bringing a modern feel to the site (making it both responsive and highly performant).  The major redesign project requires a lot of thinking about how to do things differently, improving reader experience and writer productivity at the same time.  Once I pulled the data on engagement and traffic numbers, the rest was making product calls every step of the way.

As for me, I adopt a blended approach, slightly tilting toward the intuition side.  I don’t believe in purely making calls intuitively.  Even my personal hero Steve Jobs made mistakes with Lisa and NeXT, lacking product-market fit.  However, purely basing everything on data means that you are hampered from experimenting.  This is particularly crucial when you are entering a new market or defining a new feature.

Apple and other like-minded companies use an intuitive approach to create products.  Consumers don’t know what they want.  Henry Ford, on innovation, said, that “If I had asked people what they wanted, they would have said faster horses.” Other successful tech companies, including Amazon and Netflix, fervently adopt a data-drive decision making approach.  Both can be successful.  Having worked at a number of tech companies, I’d like to share scenarios in which one approach is more applicable than the other.

Intuition

  • You are developing an MVP (minimum viable product).  Make the hard call on what is necessary in your first version.
  • Usability – you should use beta users or existing customers for feedback on products once the project reaches the “feature complete” milestone.  However, if your gut always tells you that this doesn’t work, trust your instinct.  You won’t find a good test result from a feature you yourself don’t believe in.

Data Driven

  • You just launched a new feature.  Track its engagement for a week, a month, 3 months.  Don’t over-react when a feature is not doing well initially.  After a one month for most consumer products, you’ll see a steady pattern.
  • Pricing changes – any revenue-impacting changes should be tested via A/B tests.
  • Product design – I am not talking about visual design.  You can show mocks to friends, coworkers and family to get some feedback.  It’s easier to get and swallow harsh feedback before you invest time in coding an iOS app.  Much easier to get the feedback when it’s in the “mockup” stage.

I would love to hear from fellow product folks about when you should trust your instinct and when you should examine data thoroughly before making a product call.

Share this:

  • Twitter
  • Facebook
  • Email

Like this:

Like Loading...

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • February 2023
  • August 2016
  • October 2015
  • July 2015
  • December 2014
  • November 2014
  • October 2014

Categories

  • books
  • career development
  • data analytics
  • design
  • eng
  • founders
  • leadership
  • PM
  • Uncategorized

Meta

  • Register
  • Log in

Blog at WordPress.com.

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy
  • Follow Following
    • Christine's Corner
    • Already have a WordPress.com account? Log in now.
    • Christine's Corner
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...
 

    %d bloggers like this: