Michelle Sun San Francisco

// Problem-focused versus Solution-focused//

Last week I had coffee with a serial entrepreneur, who started and sold two companies and currently on his third venture.  His journey was very inspiring to me.  Amidst a good conversation, he asked, “What is your dream company?” For a moment, I could not articulate an answer. 

Later that night, I reflected upon his question and realized the fundamental disconnect between my belief and his question.  I realize my mindset has shifted from building a dream product, to solving a problem. 

Focus on solving a painful problem.  One key learning I had at my previous startup, was that, if the customer would not pay for the product, the problem is usually not painful enough.  While there are many things that could have been done more, such as better sales, in hindsight, the product was too ingrained into the team’s mindset that we failed to recognize the fundamental issue - the problem was not painful enough. 

Products are usually a specific solution to a problem.  However, given a painful problem, there are countless approaches to solve that.  Focusing too much on the solution reduces resilience of the team to pivot later.  By focusing on the problem - becoming passionate about solving an unmet need - each product is viewed as an experiment to solve that problem.  If one experiment fails, move on to another one.  

Maximize learning early on.  The problem-focused mindset calls for designing small experiments to solve problems; build fast, fail fast.  Instagram started as Burbn, a location-based service.  If your product is consumer facing, use the “bar test”.  Founders Kevin Systrom and Mike Krieger validated their idea in social settings; figure out how to pitch an app to a stranger in 20 seconds, in a noisy bar.  In the case of Burbn, the lack of intuitive understanding and interest from the early testers prompted the founders to re-work the idea.  Groupon started as ThePoint, which allows users start a campaign asking people to give money or do something as a group.  The learnings from the earlier products laid foundation to the successes of the ones that followed. 

Be creative in getting the problem solved.  Many great startups survived not because of the quick reception from their target market.  Instead it was because of the conviction that there is an unmet need, they were able to be creative and use different methods to get through to their users.  To generate seed capital for their startup, the founders of Airbnb bought bulk supply of generic cheerios and created presidential election themed boxes to sell at the Democratic Convention in Denver.  Their founder Joe Gebbia described: 

We made 500 of each (Obama O’s and Cap’n McCains). They were a numbered edition on the top of each box, and sold for $40 each. The Obama O’s sold out, netting the funds we needed to keep Airbnb alive. The Cap’n McCains… they didn’t sell quite as well, and we ended up eating them to save money on food.

Go from me-focused to market-focused.  

Marry the problem  - Dane Maxwell

The problem-focused mindset allows for more flexibility in developing a solution.  Dane Maxwell said it well in his podcast, entrepreneurs should go from “me-focused” - from going after passion, skills - and shift to “what the pain of the customer and become passionate about improving their life”.  

When asked the same question again, I will say, “to solve a painful problem well”. 

Photo credit: BubbyMakesThree

// Common Pitfalls in Building Products and How to Avoid them//

image

New year is a great time for reflecting past year’s learning.  In 2012, I brought a product from ideation to market, acquired customers for it and implemented features from customer development of Lean Startup model.  I realize, there are a few common pitfalls that first time entrepreneurs, including myself, are prone to fall prey to, and how I would do differently in the next product. 

Training the empathy muscle

Building a product that people need requires a thorough understanding of customers’ values, priorities, perception, tolerances and experiences.  

Common pitfall: assume the same technological proficiency from ‘regular people’ as ourselves.  I find it helpful to speak with friends and family in different industries, such as my sister in the healthcare industry who owns one page of apps on her iPhone 4S and my high school friend who works in airline marketing who only recently opened a Gmail account.  

You may argue, the best products are those that solve the creator’s own problem.  It is true that solving our own problems helps us see the users’ (ourselves) need more clearly.  However, to make the user interface accessible, we still need to step out and think about the product from a beginner’s eyes, respect and cater to users’ technical understanding.  

Product discovery 

Making software products is a two-stage exercise, figuring out what to build and building it.  During the product discovery process, the team flushes out ideas, tests out new technologies, thinks about long term, short term product direction.  Once the team is done crafting a winning product, the focus shifts to execution. 

Common pitfall: product discovery is often treated as a scheduled task like building out a feature.  That is because engineering talent is often the most expensive asset in a startup and once received funding, startups are pressed to build as quickly as they can.  That can often be a blessing in disguise; most startups should place emphasis on product discovery and maximize learning, instead of building. 

Instead of believing “build it and they will come”, Marty Cagan, author of Inspired: How to Create Products Customers Love, recommends to focus on answering these questions:

     - Are there real users out there who want this product?  

     - Have we identified a market and how can we verify the opportunity with potential customers?

     - What is a valuable, usable and feasible product solution to this problem?

     - What technologies can I apply solve this problem in a better way?

     - What should the user experience be?

While there is no shortage of hard problems out there, the challenge is in discovering a valuable, usable solution to that problem.  That involves talking to a lot of customers.  To me, the biggest part was to learn how to ask good, open ended questions.  The goal is to learn as much about the potential customers as possible, how they perceive the problem and what are the constraints in finding a solution. 

Case study: Dropbox

After talking to venture capitalists who said they don’t use any of the cloud storage servers, despite the plethora of them in the market, Drew Houston, founder of Dropbox came up with 3 minute screen cast and received feedback from Hacker News.  The next step involved posting on Digg, to get more ‘general mass’ users.  By posting links on politics and humorous content, it attracts significant interest from the non-tech community.  All these were performed before shipping code.  His first demo video is posted below. 

Product validation

After discovering a potential solution to the problem, what follows is to find evidence that the product will be successful without building out and deploying it.

Common pitfall: to be over confident in a product spec, or an idea, and think they will adjust the product with the feedback they get when the beta version is out.  The beta version is often too late for major changes, and the time and emotional investment by the team while developing the beta product often make it costly, economically but also in terms of team morale, to pivot at that point.  

There are three types of validation: 

  1. Feasibility: Is the product going to be buildable, given time and funds available?
  2. Usability: Can users figure out how to use it? Present the prototype test in front of real people. 
  3. Value: What really matters is whether or not the product is something users will fund valuable and want to buy?  

Often, the road is windy with lots of false starts and resets.  In all, it is better to learn about the market early on than after consuming months of engineering resources.  For example, my previous startup Spotick went after the mobile loyalty space, which is a validated, large market with lots of sizable players.  However, the geographical market we went after, Hong Kong, was culturally less ready for a consumer product.  While the merchants were willing to try it out, we did not sense a willingness to pay.  In light of that, we switched to explore enterprise sales with retail and food & beverage chains, which we saw more demand and validated the value through securing marketing budgets with a handful of companies. 

Case study: Buffer  

Buffer's landing page serves as one of the best examples that I came across regarding product validation.  Founder Joel Gascoigne put up a landing page and showcased a “product’, and by checking the clicks on the potential pricing plans, he validated customer needs and willingness to pay - all before even building the product!  The details can be found here

Improve existing products. 

This is an area that I feel especially strongly about.  Once the product is out in the market, the excitement of having real users also brings in lots of opinions, sometimes contradictory, but equally passionate.  Which ones should we listen to, and when should we respond to feature requests?  

Common pitfall: to gather subjecting feedback, elicit customer requirements and chase features.  In my past experience of selling to enterprise customers, I remember clearly the allure of ‘adding just another feature’ to close the sales.  It requires a lot of discipline and determination to say no to the feature requests.  While it could feel devastating to turn away potential customers in such early stage, it is wise to avoid the slippery slope of becoming what Marty Cagan calls “feature factory”.  

A more fruitful pursuit is to focus relentlessly on the most important metrics and perform A/B testing to drive the metrics to the right direction.  

Case study: Skype

Skype was a prime victim of feature creep.  It grew from a basic communication tool to many unused, complicated features like Public Chat, Send Money.  A key sign that the product became too heavy and have too many superfluous features - releasing Skype Pro and Lite versions.  These features and products are now discontinued, as the company strives to return the product focus to core functionality. 

image

source: Skype Discontinued Features

What are the tricks that you have found useful in developing products?  What are the key difficulties in different stages of product development?  I’d love to hear about them in the comments!

Photo Credit: Collective Action Toolkit

Being design-driven means treating design as a partner (and a leader) in the product creation process. Look at your feature roadmap right now. Are there major initiatives and ideas that were generated directly from your designer or design team? If yes, was design in the room when the other items were created and prioritized? Congratulations, you’re design-driven.
Articulate two simple things:
What game are we playing?
How do we keep score?
————————————-
Do these two things right, and all of a sudden a collection of brilliant individual contributors with talents in engineering, operations, quality, design and marketing will start running in the same direction.
blog comments powered by Disqus
I work at Buffer on metrics/growth. Here I share about startups, personal improvement and wellness.
I'd love to hear from you!