Product Managers: Vision, Instinct & Obsession "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 18 October 2014 True Product Culture, Product Management Role, Mind the Product Mind the Product Ltd 1012 Product Management 4.048
· 5 minute read

Product Managers: Vision, Instinct & Obsession

I wanted to note down my experience of the product management role as after speaking to a few startup founders I’ve heard a lot of differing opinions, at least here in London.

(In this post I’ll use the word customer over the word user as I prefer it. User sounds a bit hollow).

The basics

Good product management involves many different disciplines and a good product manager should know each of them inside out. Below is a brief flow describing the basic things that should be considered:

Product management: Purpose, Scope, Design, Develop, Measure

Let’s take a look at each segment, starting with the business model:

Purpose:

You need to know your business model. (A good resource for visualising a business model is Alex Osterwalder’s Business Model Canvas (great video), by mapping out yours you can understand the different moving parts). The pieces of the model you should really understand are the:

  • Value proposition – what it is you’re offering customers, what it is you’re promising them;
  • Customer segments – who your customers are, what makes them tick, how they normally behave, what they like and dislike.

(Other pieces you should know, although these may not be defined yet, are the:

  • Channels – how your customers will find you and how you’ll be attracting more of them;
  • Revenue streams – how your product will make money, if applicable).

After you know what you’re offering and to whom, you need to understand the market you’re in, your competitors and what they’re up to. Your goal should be to out-innovate them.

Scope:

To some extent, the value proposition will dictate the form the product will take, but the rest will be instinct and vision. For example, if you’re letting customers buy stuff, then you’re looking at some sort of ecommerce product. Or is it about sharing opinions, feelings or photos? Or about organising information? Storing data? Creating content? Consuming content? Are you going to digi-fy a real world activity or create a new paradigm or abstraction? You should be thinking about how your customers will use your product: at home on a desktop, out on a tablet/phone. Do you need to be mobile-first? Responsive-web or native?

Design:

This is where you start bringing it to life and to me, along with development, this is most fun and fulfilling part. The problem has been defined and now you start solving it. Start with a white board and sketch out the big picture in terms of user flow and actions. Then zoom in and wireframe individual parts on paper. User test your paper mockups and use the feedback to iterate continuously until you have a solid flow and experience.

Think about how you want your customers to feel when using your product. How can you delight them? What are the high points you can exploit? How can you get them hooked? Mentioning your product to their friends?

From a design perspective, the point isn’t to produce something that’s pixel-perfect, but to get to a point where you can start building and iterating over it. Note that there are some things you’ll only notice once you’ve built and used it.

Great designers are key here as well as your ability to convey your vision to them. A technology background is also important as you’ll know what is and isn’t possible, as well as what is and isn’t good user experience.

Develop:

Break the scope down into features, build them and ship them. It’s important to know how developers work, e.g. with agile and XP practices.

From experience, the closer the relationship is between the designers and developers, the tighter the feedback loop will be and the higher the quality of the end result.

Again, your ability to convey your vision to your developers will make or break your product. Ideally you should live and breathe development, or find someone who does.

Tight team:
Tight team: Whilst coming up with Pocket Shop’s 2nd MVP I sat directly next to designer (Peter Main). We sketched out high-level interaction on a whiteboard then drilled down and sketched out individual interactions on paper. These wireframes lived in the middle of the desk as I built it and Pete added polish. We built, user tested, rinsed and repeated non-stop for 3 days. The MVP went on to be the final product (see our Design Week article for screen shots of what we built). The point is not to dive in and write code, but to create the working environment where this high level of collaboration can happen.

Measure:

Your metrics will tell you how well your product is performing against your goals and value proposition, so take measurements that are appropriate. Start with basic interactions, e.g. what percentage of people added something to their basket? Or uploaded a photo? Entered information? Then drill down into each interaction and collect more specific data, e.g. how big was each basket? How long did it take to add something to a basket?

This will not only tell you how your product currently performs, but gets you thinking about what improvements you can make. Use this data as well as qualitative feedback from real customers to iterate and improve.

The stuff that makes a difference

The above is a whirlwind workflow which will by no means guarantee success. If the above was a recipe for a dish, then what’s not been mentioned is the vision, instinct, obsession for quality and execution ability of the chef… our product manager.

The product manager ties together all the elements (the value proposition, the customer) with the disciplines that make it happen (design, development and marketing) and adds their own product magic to execute, continuously iterate and deliver.

Your thoughts

These observations come from a specific context which in this case was a relatively early-stage team. As such, the role will vary heavily based on the product, culture and stage of company.

I’m keen to hear your definition of a product manager so please leave a comment below, tweet me or drop me an email.

Comments 1

Hi Hemal! Good Post. In this producy development flow I would exchance your Scope phase into something like a MVF (Minimum Viable Feature). Since in the Purpose stage you´ve made some assumptions (of course alredy based on numbers) to base your business model on, it´s really important to verify and validate your assumptions before even design your solution. Designing something to be developed before test and validade your business model could create some wastes that with a MVF you could verify and evolve it so you can take a better decision on develop or not something.

The things you suggest in the Scope phase are very similar or could be merged to a Design moment.

Join the community

Sign up for free to share your thoughts