Posts

Showing posts with the label Product management challenges

Help Me Help You: Getting Great Consumer Insights

Image
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 r...

Creating Culture Through Prototype Development

Image
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...

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: “t he 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 ...

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 ...

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,...

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...

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 st...

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 dif...