Learning from Roman Pichler about Agile Product Strategy and Roadmap

A few months ago I did a course titled Agile Product Strategy and Roadmap by Roman Pichler. Roman is a London-based Agile & Lean product management expert, who published the book Agile Product Management with Scrum a few years ago. Roman’s course was all about how to best create a product strategy and an effective product roadmap. These are the main things that I learned during this course:

  1. Why the need for a more iterative product strategy? – Roman kicked off the course by talking about more traditional ways to formulate a product strategy. Traditionally, a company would do lots of market research upfront, spend a lot of time on a solid business case and then create a long-term product roadmap. The perceived benefits of this approach are a sense of risk management and a sense of thoroughness. I would argue that a long winded product strategy formulation process can result in a false sense of reassurance. Speed to market is key and I believe that most companies simply can’t afford to spend loads of time and effort doing upfront research or planning. Roman made the case for a much lighter process; a quicker way of assessing market/product opportunities and an iterative process of testing product assumptions.
  2. ‘Just enough market research’ – Instead of spending ages carrying out market research and analysis upfront, Roman talked about doing ‘just enough’ market research. When you apply a ‘lean’ approach of testing assumptions and hypothesis (see my earlier blog posts about assumptions here), you should do just enough market research to test any key risks or leap of faith assumptions.
  3. Product vision – A number of the course attendees were keen to find out more about how to best create a product vision. Roman explained the main function of a good product vision: to provide the “why”, the underlying motivation for a product that you’re looking to develop. What’s the impact or change that you’re looking to achieve and why? A business vision or product vision provides you with guidance, a continued purpose. We talked about the often misused lean concept of the “pivot” (a term coined by Eric Ries, founder of the Lean Startup movement). The idea is that when a company pivots, it means that it changes its approach or tactics whilst staying grounded in its vision. Roman then went on to talk about the characteristics of a good product vision and running a vision workshop (see Fig. 1 and Fig. 2 below).
  4. Product roadmap – Roman spent a good part of the course talking about the value of a good product roadmap, which was very helpful. Prior to this course I had already used Roman’s template for a Goal Oriented Roadmap, which I’ve found to be a great tool for combining product strategy with specific business or product objectives (see Fig. 3 below). Roman explained that a product roadmap communicates how a product is likely to evolve over time. He suggested that the younger your product is, the shorter your roadmap horizon should be. For example, with young products, the time span of your product roadmap should be no more than 6-12 months. The other thing Roman mentioned, which I feel gets often overlooked, is that the creation of a roadmap is a collaborative process. One of the reasons why I particularly like the Goal Oriented Roadmap is that this template is very easy to extend to suit one’s specific purposes. For instance, if you’re looking to create a roadmap for a portfolio of products or for specific releases, then it’s easy to adjust the “GO” roadmap template accordingly (see Fig. 4 below).

Main learning point: Roman’s Agile Product Strategy and Roadmap Course is great for anyone who wishes to learn more about more ‘holistic product thinking’; creating a product roadmap and being clear on why certain products/features are on the roadmap (and others aren’t). The key thing for me is Roman’s goal-oriented product roadmap, a great tool for combining product milestones with specific business goals.

Fig. 1 – Characteristics of a good product or business vision by Roman Pichler – See http://www.romanpichler.com/blog/tips-for-writing-compelling-product-vision/

  • Think big – A good vision is lofty and aspirational.
  • A shared vision – Create a common sense of purpose which is shared widely across the company.
  • Motivating – Outlines the benefits that the product or service creates for others.
  • Short and sweet – A good vision is easy to understand and to communicate.
  • Use for decision-making – Use your vision as guide when making business or product decisions.
  • Distinguish between vision and strategy – A vision should not be a plan that outlines how to reach a goal.

Good examples of a compelling vision:

Toys”R”Us – Taken from: http://www.toysrusinc.com/about-us/vision-values/

Toys

Mozilla Firefox – Taken from: https://wiki.mozilla.org/Firefox/VisionStatement

Screen Shot 2015-01-27 at 08.36.04

Fig. 2 – Running a visioning workshop – See also: http://uxmag.com/articles/creating-a-shared-vision-that-works

  • Goals – (1) To get buy-in for the vision early on from a range of internal and/or external stakeholders and (2) to leverage the knowledge of the group to come to an agreed product vision
  • Have a rough idea of the vision beforehand – As a product person, it’s important to already have an idea of the what the initial product vision and direction should like like. This will help in facilitating the workshop.
  • Listen, but don’t end up making weak compromises – Especially when you’re doing a visioning workshop with a large group of stakeholders, it’s important to listen to the different viewpoints but not making weak compromises on the vision ‘just to keep everybody in the room happy’.
  • Consider stages of market maturity – What stage is your target market in? What is the competition like and what are their differentiators? What are the needs of your market segment?

Fig. 3 – Template for the Goal Oriented Roadmap by Roman Pichler – Taken from: http://www.romanpichler.com/blog/goal-oriented-agile-product-roadmap/

GOProductRoadmapExplained

Fig. 4 – Ways in which to add to the Goal Oriented Roadmap template by Roman Pichler

  • Product portfolio planning – Add an extra layer to your product roadmap to outline dependencies between products, specific “portfolio goals” and to highlight where products fit within your portfolio. Roman suggested using the BCG Matrix to qualify products within the portfolio: “stars”, “cash cows”, “question marks” and “dogs”.
  • Product release planning – Add another layer to your product roadmap to indicate budget/costs per product release or milestone. This helps in assessing the so-called “project management triangle” per individual release (see Fig. 5 below). You can then link a backlog with features specific to each milestone on the roadmap.

Fig. 5 – The Project Management Triangle, managing the ‘triple constraint’ – Taken from: https://programsuccess.wordpress.com/2011/05/02/scope-time-and-cost-managing-the-triple-constraint/

 

triple-constraint

Book review: “Designing for Behavior Change”

This article was first published in August ’14 on http://www.nirandfar.com/2014/08/designing-for-behavior-change-book-review.html

Behavioural economics, psychology and persuasive technology have proven to be very popular topics over the past decade. These subjects all have one aspect in common; they help us understand how people make decisions in their daily lives, and how those decisions are shaped by people’s prior experiences and their environment. A question then arises around what it means to change people’s behaviours and how one can design to achieve such change.

Stephen Wendel, a Principal Scientist at HelloWallet, has written “Designing for Behavior Change”, which studies how one can apply psychology and behavioral economics to design for behavior change. In this book, Stephen Wendel introduces four stages of designing for behavior change: Understand, Discover, Design and Refine (see Fig. 1 below):

  • Understand – The process starts off with gaining an understanding of how people make decisions and how our cognitive mechanisms can support (or hinder) behavior change.
  • Discover – The second stage is about a company working out what it wants to accomplish with the product, and for whom.
  • Design – The actual design stage can be broken down into two subtasks: (1) designing the overall concept for the product and (2) designing the specific user interface.
  • Refine – Analyzing data to generate insights and ideas for ongoing improvement of the product.

Stage 1 – Understand

The Understand stage is all about understanding how people make decisions and how the mind decides what to do next. There is a clear distinction between the deliberative and the intuitive mind. Our deliberative or “conscious” mind tends tends to be slow, focused and self-aware. In contrast, when people are in an intuitive or “emotional” mode they are likely to act on “gut feeling”, fast and unaware. Most of the time, we are not consciously deciding what to do next. Instead, we often act based on habits. Even when we do think consciously about what to do next, we actively try to avoid hard work.

“Designing for Behavior Change” stresses the importance of being very clear about the type of behaviour one is trying to encourage: a conscious choice or an intuitive response. Stephen Wendel proposes a simple but powerful model – “Create” – which helps to understand what products need to do to get users to take a particular action:

  • Cue – A cue for users to think about what to do can either be internal or external. External cues happen when there is something in our environment triggering us to think about a certain action. Internal cues are the result of our minds thinking about the action on its own, through some unknown web of associated ideas.
  • Reaction – Once the mind has been cued to think about a potential action, there is an automatic reaction in response. This reaction tends to be intuitive and automatic.
  • Ability – Assuming the choice has been made to act, the question arises whether it is actually feasible to undertake the action. Wendel suggests that the individual must be able to act immediately and without obstacles.
  • Timing – When should you take the action? The decision when to take action can be taken based on a sense of urgency, and by other, less forceful factors.
  • Evaluation After an initial intuitive response, there might be room for a more conscious evaluation of the action and of potential alternatives. This happens especially when we are facing novel situations, and we do not have an automatic behavior to trigger.

These five mental events can be best summarized through the “Create Action Funnel” (see Fig. 2 below). The main point to make with respect to this funnel, is that people can drop out out at each stage. A person will most probably only continue through the funnel if the action is more effective or better than the alternatives.

“Strategies for Behavior Change” is the third and final output of the Understand stage. The book suggests three possible strategies to consider:

  • Cheat – If what you really care about is the action getting done, and it is possible to all but eliminate the work required of the user beyond giving consent, then do it.
  • Make or change habits – If the user needs to take an action multiple times, and you can identify a clear cue, routine, and reward, then use the “habits” strategy (see Fig. 3 below).
  • Support conscious action – If neither of the two aforementioned strategies is available, then you must help the user consciously undertake the target action.

Stage 2 – Discover

The second stage of Stephen Wendel’s designing for behavior change process is the Discover stage. The main goal is of this stage is to figure out what it is that one wants to accomplish with the product. Wendel identifies five distinct steps with regard to discovery:

  1. Clarify the overall behavioral vision of the product.
  2. Identify the user outcomes sought.
  3. Generate a list of possible actions.
  4. Get to know your users and what is feasible and interesting for them.
  5. Evaluate the list of possible actions and select the best one.

When thinking about “target outcomes,” you can think about what both the company and the user aim to accomplish with the product. You can then clarify this outcome by asking yourself some of the following probing questions:

  • Which type? – Does the product ultimately seek to change something about the environment or about people?
  • Where? – What is the geographic scope of the impact?
  • What? – What is the actual change to the environment or person?
  • When? – At what point should the product have an impact?

Within the Discover process, a lot of emphasis is placed on finding the “Minimum Viable Action.” This is the shortest, simplest version of the target action that users must take so that you can test whether your product idea (and its assumed impact on behavior) works.

At the end of the Discover stage, you should have detailed observations about your users, a set of user personas, and a clear statement of the target outcome, actor and action.

Stage 3 – Design

Wendel then goes on to explore the Design stage. The purpose of this stage is to create a context that drives action. There are three key aspects to this process:

  1. Structure the action – To ensure that an action is feasible and inviting for the user. Creating a “behavioral plan” can be a good way to outline the different steps users should take from what they are doing now to using the product and completing the target action. This can be a simple flowchart or a written narrative; the key objective here is to think about the sequence of real world steps a user needs to take to complete an action.
  2. Design the environment – To ensure that the environment is constructed in such a way that it supports the action. When talking about “environment,” Wendel means two things. Firstly, the product itself. For example, a web page or smartphone where a user takes an action. Secondly, the user’s local environment, which can be both physical and social. Wendel then goes on to identify a number of ways in which products can construct an environment, e.g. by increasing the motivation for people to act or by generating a feedback loop.
  3. Prepare the user – How does one prepare the user to take action? Stephen Wendel suggests three tactics which can help to prepare the user to take action, now or in the future: “narrate” (change how users see themselves), “associate” (change how users see the action) and “educate” (change how users see the world).

Stage 4 – Refine

Refine is the fourth stage of the behavior change process. This stage is all about learning about how people actually use the product, its behavioral impact and identifying areas for improvement. There are three main components of this stage:

  • Impact Assessment – Measure the impact of the product, based on clear target outcomes and well defined metrics for each outcome. Here it is important to set clear thresholds for success and failure.
  • Identifying obstacles to behavior change – Discover problems, develop potential solutions and generate additional ideas for how to make the product better. One can start this process by watching real people using the product (direct observation) and by gathering usage data. We can thus start getting a better insight into how people use the product, what the bottlenecks are, where the product is having the most impact on people, etc.
  • Learning and refining the product – Determine what changes to implement through (1) gathering lessons learned and potential product improvements (2) prioritizing potential improvements based on business considerations and behavioral impact and (3) integrating potential improvements into the appropriate part of the product development process.

“Designing for Behavior Change” offers good insight into how to best design in order to impact human behavior. Not the easiest of topics, Stephen Wendel provides a clear framework against which we can think about the behavior a product needs to impact and how to best achieve this impact.

Fig. 1 – Stages and outputs per stage of the designing for behavior change – Taken from: “Designing for Behavior Change” by Stephen Wendel, Preface-4

Stephen Wendel 1

 

Fig. 2 – The Create Action Funnel – Taken from: “Designing for Behavior Change” by Stephen Wendel, p. 40

Stephen Wendel 2

 

Fig. 3 –  The Habit Loop by Charles Duhigg – Taken from: “Designing for Behavior Change” by Stephen Wendel, p. 59

the-habit-loop

 

App review: OpenTable

“The UK’s number one restaurant booking website” is what it says on the homepage of http://www.opentable.co.uk/. One of the reasons why I was keen to find out more about OpenTable is the fact that it serves two types of customers since its connects restaurateurs with customers. This is a similar mechanism which Carwow specialises in, a website which I reviewed previously.

This is my review of OpenTable’s iOS app:

  1. How did this app come to my attention? – I found out the other day that “TopTable”, a restaurant booking site which I’ve used in the past, had been taken over by OpenTable. It’s always good to have a restaurant booking site at hand, reason why I decided to give OpenTable a try and do a quick review.
  2. My quick summary of the app (before using it) –  This is a restaurant booking site. I expect to be able to discover and book restaurants in my local area through this site.
  3. How does the app explain itself in the first minute? – Straightforward; a list of restaurants that I can book (see Fig. 1 below). Because I’ve enabled location tracking, the suggested restaurants are all in the area from where I’m accessing the app. I can view available time slots per restaurants as well as star ratings and proximity.
  4. Getting started, what’s the process like (1)? – I first decided to change the default setting from “Table for 2, today at 12:00” to 2 people on Sun 25 Jan at 12:00. I then select “Chamberlain’s Restaurant” at 12:00, after which I get presented with a nice landing page for Chamberlain’s Restaurant (see Fig. 3 below). By default, the “Info” view is displayed for a restaurant, which means that the view offers practical info such as price range, cuisine and parking. When I switch to the “Reviews” view, I see that the restaurant is rated based on four criteria: food, service, ambiance and value (see Fig. 4 below).
  5. Getting started, what’s the process like (2)? I then click on the red “12:00” button, after which I click on the “Reserve as a guest” button (see Fig. 5 below). Signing up as a guest is simple, I just need to enter my first name, last name, email and phone – all the info I expect to submit when making a restaurant reservation (see Fig. 6 below).
  6. How easy to use was the app?  Very easy and intuitive. Granted, I didn’t do the whole Open Table sign-up process, but the design of the app is simple and provides the functionality that you’d expect.
  7. How does the app compare to similar apps?  I had a play with the iOS app of Bookatable, which felt very similar to Open Table. Whereas OpenTable seems to focus very much on displaying available time slots (see Fig. 1), Bookatable concentrates more on providing appealing visuals and highlighting good restaurant deals or “offers” (see Fig. 7 below). Another example, US oriented Resy, looks quite basic in comparison (see Fig. 8 below).
  8. Did the app deliver on my expectations? – Yes, although I expected the app to work harder on ‘drawing’ me in, explaining the benefits of OpenTable and really encouraging me to pick one of the restaurants recommended. The iOS app provides an easy to use and intuitive experience, but I believe it could provide a more compelling experience (see Fig. 9 below).

Fig. 1 – Screenshot of the first screen of the OpenTable iOS app, based on my location

OpenTable1

Fig. 2 – Screenshot of date and time selector on the OpenTable iOS app

OpenTable 2

 Fig. 3 – Screenshot of the landing page for “Chamberlain’s Restaurant” on the OpenTable iOS app

Chamberlain's

Fig. 4 – Screenshot of “Reviews” view on OpenTable iOS app 

OpenTable 6

Fig. 7 – Screenshot of the step prior to making a booking through the OpenTable iOS app

Carwow 7

Fig. 6 – Screenshot of information required to make a reservation through the OpenTable iOS app 

OpenTable 8

Fig. 7 – Screenshot of the first screen of the first screen of Bookatable’s iOS app, not based on my location 

Bookatable 1

Fig. 8 – Screenshot of the first screen on Resy’s Android app

Resy

Fig. 9 – Some initial suggestions to make OpenTable more compelling

  • Highlight ‘hard to get’ bookings – Similar to US apps like Resy and Shout, it would be interesting if OpenTable were to highlight certain restaurants,e.g. based on reputation (and difficulty of getting into) or based on price.
  • Personalised recommendations – Once I’ve made a few bookings through OpenTable, I expect to see or receive more personalised recommendations. I can imagine that OpenTable are already looking at best ways to engage with and retain their users, encouraging ‘personalised discovery’.
  • Visually appealing – Some of the imagery currently available through OpenTable is fairly bland and nondescript. I feel that rich imagery can act as an first important pull to get the user to make a booking or to look at the available menu options or reviews for each restaurant.

Related links for further learning:

  1. http://www.fsrmagazine.com/marketing/pros-and-cons-opentable
  2. http://www.quora.com/Are-there-OpenTable-competitors-If-so-who-are-they-and-how-are-they-doing
  3. http://www.theguardian.com/lifeandstyle/wordofmouth/2014/jun/17/restaurant-booking-apps-shout-resy
  4. http://www.dailymail.co.uk/sciencetech/article-2655722/Want-dinner-exclusive-restaurant-craving-cronut-The-apps-lets-jump-queue-New-York-price.html
  5. http://www.bloomberg.com/news/2014-06-10/reservation-startups-will-snag-you-a-table-for-a-fee.html
  6. http://techcrunch.com/2014/10/28/reserve-from-startup-studio-expa-makes-restaurant-reservations-easier-than-ever/
  7. http://startups.co.uk/restaurant-booking-website-bookatable-acquires-nordic-competitor-2book/

Learning about the basic constructs of XML

A few weeks ago I wrote about relational data models and databases and some of the basic principles which I learned about in an online Stanford course. As part of the same course I recently learned about “XML” which stands for Extensible Markup Language, a standard for data representation and exchange. Having worked in the entertainment industry for a few years now, I’ve often find myself looking at metadata in the form of XML, but it was great to get a good refresher as part of my course.

These are some of the basic constructs of XML:

  • Tagged elements (nested) – an opening and a closing tag
  • Attributes – attributes tend to consist of: a name (unique), an equal sign (=) and an attribute value
  • Text – also known as “character data”, this can be as simple as “Marc Abraham” or “123456”

The instructor, Jennifer Widom, then went on to explain the differences between the relational data model and XML:

Relational data (eg. SQL):

  1. Structure: Tables
  2. Schema: Fixed in advance
  3. Queries: Simple, nice language
  4. Ordering: None, unordered
  5. Implementation: Native

XML:

  1. Structure: Hierarchical tree, graph
  2. Schema: Flexible, “self-describing”
  3. Queries: Less simple, more complex
  4. Order: Implied ordering
  5. Implementation: Add-on

With XML, validation is a key aspect. In an oversimplified way, it comes down to taking an XML document and validate it against a set “XSD” (XML Schema Descriptor). This process determines whether the XML document is valid or invalid (see Fig. 1 below). During the class, Jennifer also highlighted that XML documents contain two file types. First, a schema file which contains the XSD. Second, the actual data file.

I then struggled a bit when Jennifer talked about “DTDs”. I subsequently learned that “DTD” stands for ‘Document Type Definition’ and is a set of markup declarations which defines the legal building blocks of an XML document.

There are four features of an XML schema which aren’t present in DTDs:

  • Key declarations – In DTDs, document or item IDs have to be globally unique. An XML ID can be specified through an attribute value only. This means that you can’t index elements in the XML based on a parent-child relationship (see Fig. 2 below). Key declarations in XML aim to overcome such limitations.
  • Type values  XML Schema has a lot of built-in data types. The most common types are string, decimal, integer, boolean, date and time. I’ve found some useful examples of ‘simple type’ and ‘complex types’ XML schema (see Fig. 3 below).
  • References – References can refer to already defined keys (see my previous point about key declarations) or so-called “typed pointers”. A typed pointer must point to a specific element of the XML (e.g. a string) which in term must confirm to the specification as laid out in the pointer.
  • Currents constraints  In XML one can specify how many times an element type is allowed to occur. One can thus specify a minimum and a maximum number of occurrences.

Main learning point: In her online video on the basics of XML, Jennifer Widom provided a useful overview of XML. Even though I had looked at XML schema before, it was good to understand more about some of the foundations behind XML and XML validation.

Fig. 1 – Sample XML validator – Taken from: http://www.deitel.com/articles/xml_tutorials/20060401/XMLStructuringData/XMLStructuringData_Page4.html

validateLetter1

 

Fig. 2 – Sample XML, highlighting XML ID requirement – Taken from: http://msdn.microsoft.com/en-us/library/aa302297.aspx

<?xml version="1.0"?>
<!DOCTYPE orders [
  <!ELEMENT order ANY>  
  <!ATTLIST order
    orderno ID #REQUIRED   
  >  
]>
<orders>
  <order orderno="id10952" date="4/15/96" shipAddress="Obere Str. 57"/>
  <order orderno="id10535" date="6/13/95" shipAddress="Mataderos  2312"/>
</orders>

 

Fig. 3 – Examples of simple type and complex type XML schema – Taken from: http://www.xmlmaster.org/en/article/d01/c05/

Simple Type Example

<xs:element name=”Department” type=”xs:string” />

Here, the section described together with “xs:string” is an embedded simple type according to XML Schema. In this example, we have established the definition that the data type for the element called “Department” is a text string.

Complex Type Example

<xs:complexType name=”EmployeeType”>
<xs:sequence maxOccurs=”unbounded”>
<xs:element ref=”Name” />
<xs:element ref=”Department” />
</xs:sequence>
</xs:complexType>
<xs:element name=”Name” type=”xs:string” />
<xs:element name=”Department” type=”xs:string” />

In this case the type name “EmployeeType” is designated by the name attribute of the complexType element. A model group (what designates the order of occurrence for the child element) is designated in the child element.

New types are created by placing restrictions on or extending simple or complex types. In this volume, we will discuss restrictions and extensions for simple types.

Related links for further learning:

  1. http://www.rpbourret.com/xml/XMLAndDatabases.htm
  2. http://stackoverflow.com/questions/966901/modeling-xml-vs-relational-database
  3. http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.1.0/com.ibm.db2.udb.apdv.embed.doc/doc/c0023811.htm
  4. http://www.deitel.com/articles/xml_tutorials/20060401/XMLStructuringData/XMLStructuringData_Page4.html
  5. http://en.wikipedia.org/wiki/Document_type_definition
  6. http://www.w3.org/TR/xmlschema-1/
  7. http://msdn.microsoft.com/en-us/library/aa302297.aspx
  8. http://www.w3schools.com/schema/schema_simple.asp
  9. http://www.xmlmaster.org/en/article/d01/c05/
  10. http://www.w3.org/TR/xptr-framework/
  11. http://www.xmlnews.org/docs/xml-basics.html

 

 

Some dos and don’ts for product managers

Do you ever wonder what to do when you start a new job!? How do you get a good sense of what’s going on and when can you start making some sort of an impact? Ken Norton, Product Partner at Google Ventures, has written a great article which offers practical tips to product managers on things they do should do during the first 30 days into their new job. In the article, Ken’s overarching focus is on “people, product and personal”.

This is my summary of Ken’s suggestions, combined with some of my own experiences and learnings:

People:

  • Review your objectives with your CEO or manager – Like Ken suggests, I believe it’s very important to set expectations with your line manager of CEO on your objectives as a product manager. Identify and agree upfront what success will look like in your role. Especially as product management can be a fairly new discipline in lots of organisations, it’s important to manage expectation from day one.
  • Schedule one-to-ones – Whenever I start a new job, I tend to spend the first week just having one-to-one conversations with a variety of people across the business. My main goals for having these conversations are twofold. Firstly, I use these chats to get an initial sense of people’s responsibilities, their biggest challenges and how I can be of help to them. Secondly, it gives me an opportunity to introduce myself in an informal setting rather than in a meeting with lots of other people. Especially in cases where I work closely with a dedicated team, I’ll spend a lot of time talking to individual team members and exploring what makes them tick (and what doesn’t) and again see how I can help.

Product:

  • Spend time with your lead engineer and ask ‘dumb’ questions – I believe that product management ultimately is a team sport. Your lead engineer can play a vital role in this and I find it very helpful to spend quite a bit of time with him/her in the first couple of weeks of a new role. Especially since my background isn’t in engineering, I’ll tend to listen A LOT and ask many ‘why’ and ‘how’ type questions. I can imagine that some of my questions might well be perceived as ‘dumb’ (although dumb questions don’t exist in my world), but I’d rather ask and find out than not.
  • Don’t jump in too quickly – I know from experience how tempting it can be to get stuck in straight away. However, I fully agree with Ken’s point about taking your time before you start making changes. Allow yourself some time to speak to people, key problems and their nuances and to build up a good picture of the business and its customers.
  • Talk to users – A good way to learn about a product that you’re not fully familiar with is to talk to (target) users. Ken talks about spending a good amount of your early days with users. Meet with users or clients, see and hear how they interact with your product. Spend some time with the Customer Services team to take some calls and look into support issues. Whether you work in a B2B or B2C environment, it’s really important to quickly get a first sense of your target audience, their needs and how your product or service addresses those needs. As a product manager you’ll interact with (target) customers on an ongoing basis, and I believe one should use the first weeks of a new role to start these interactions, and learn about the customer and their needs/behaviours.

Personal:

  • Read up and write about it – It helps to read things related to your product – old specs, design documents, wiki pages, etc. As you find documentation that is missing or out of date, add to it. Especially if the domain of your product is new to you, I’d encourage you to read, talk and listen to find out as much as you can about your product, its proposition and its users. Spend some time to write up what you’ve learned.
  • Understand the business, its competitors and the market – Don’t limit yourself to just understanding your product or your external customers. As a product person, I believe it’s just as important to understand the business as a whole. What’s the business model? What levers drive the performance of your business and why? Creating an understanding of such things will help you in having a wider context around the products that you’ll be working on. Similarly, you want to figure out who your internal ‘customers’ or stakeholders are. Who are the internal people with a clear interest in the product, its development and performance? How would they like to be communicated with? Starting to build a rapport with these internal stakeholders is critical for you as a product manager.
  • Set personal goals – Apart from the specific OKRs that will have been set by the organisation for you and your product, Ken suggests setting your own personal development goals. For example, one of my personal development goals when I started a new role a few months ago was to use more data to inform my product decisions.

In the same week that I came across Ken’s suggestions about things product managers should do in their first month, I also read two interesting articles on 4 Mistakes New Product Managers Make and Why Most Product Managers Suck (And How To Be A Better One). You can find my summaries of both articles in Fig. 1 and 2 below respectively.

Main learning point: Even though product management can be a hard job to get ‘right’, there are a number of things that you can do as a product manager in the first days in your new job to learn and to determine how you can best contribute. If I had to sum up Ken Norton’s great article in one word, I’d go for “listening”. Lots of product people talk about humility, and whilst that’s absolutely right, in practice this to me means an awful lot of listening, asking the right questions and being able to make (snap) decisions based on your understanding of things.

Fig. 1 – “4 Mistakes New Product Managers Make” by Matt Schnitt – Taken from: http://dev.hubspot.com/blog/4-mistakes-new-product-managers-make and combined with some of my own experiences and learnings

  1. That’s not our user – Don’t write off user opinions too quickly. Matt makes a great point in that “great products almost never solve for a single persona or need”. With a lot of products there are a lot more prospective users who might not exactly fit your ideal user persona than the ones that do.
  2. We can’t kill it – Be brave enough to acknowledge when a feature isn’t working. Your user doesn’t care that it was an incredible technical challenge to implement. Your user doesn’t care that it took 4 weeks and 3 full-time engineers to build. And they certainly don’t care that you may lose some respect among your team for admitting defeat. I agree with Matt’s point that it’s all about the optimal experience for the user, finding the best way to solve their problems.
  3. Thinking only about solutions – When I first read this suggestion, I thought that this might be a bit of a contradiction in terms. As a product manager, when your confronted with a problem your first inclination is think about possible solutions. The risk with this, however, is that you might not spend enough time looking into the exact nature and scale of the problem. What’s the user problem that your product is trying to solve? What aspect of the current solution is causing the users issues and why?
  4. It’s not ready yet – Like Matt, I’ve seen plenty of people spending a lot of time (and postponing launches as a result) trying to polish their product, adding to scope and making more tweaks to the product. I’ve learned over the years to become better at defining and communicating the ‘product baseline’; establishing what the product should do as part of its first release and sticking to that. This implies that as a product manager you’ll need to feel comfortable making tough calls at times and saying ‘no’ as a result.

Fig. 2 – “Why Most Product Managers Suck (And How To Be A Better One)” by Vik Singh – Taken from: http://thenextweb.com/entrepreneur/2014/05/11/product-managers-suck-better-one/

  • Innovate through minimalism – The best product thinkers know how to carve down the scope of the product until it makes even more sense, as opposed to adding more and more superfluous features.
  • Prioritise ruthlessly – Product managers help prioritise the development calendar for engineering, and to do that you need to have excellent organisation skills and the ability to make difficult trade-off’s quickly. Vik gives a great of a product manager who he worked with at Yahoo and who had “the ability to ignore the noise and instead focus on the most important issues, standing up for what he felt was right”.
  • Influence without authority – Good product managers know that the “manager” part of their title is a misnomer, and can build respect from engineers and engineering managers without formal authority. You do this by being extremely good at assessing the costs of features in terms of time and impact. This helps to build trust with engineering and sales that you know what you’re doing, and that they can depend on you to make the right hard calls.
  • Communicate with presence – Product managers are responsible for interfacing with not just engineering and marketing, but also customers and company executives. Being able to write and speak clearly and persuasively is key for getting folks excited about what you’re building, ensuring they understand the requirements, and presenting yourself as a reliable source for product information.

 Related links for further learning:

  1. http://feltpresence.com/articles/14-advice-for-product-managers
  2. http://www.pminheels.com/2014/07/just-say-no-prioritization-and-product.html
  3. http://thenextweb.com/entrepreneur/2014/07/24/12-things-product-managers-first-30-days-new-company/
  4. http://dev.hubspot.com/blog/4-mistakes-new-product-managers-make
  5. http://www.cindyalvarez.com/best-practices/the-myth-of-the-self-starter
  6. http://thenextweb.com/entrepreneur/2014/05/11/product-managers-suck-better-one/
  7. http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf
  8. http://web.stanford.edu/class/e140/e140a/handouts/ProductMgmt.txt
  9. http://blogs.hbr.org/2013/09/when-youre-innovating-resist-l/
  10. https://www.youtube.com/watch?v=mIBccpqUcgY
  11. http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider
  12. http://www.quora.com/Product-Management/What-distinguishes-the-Top-1-of-Product-Managers-from-the-Top-10/
  13. http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf
  14. http://www.svpg.com/good-product-team-bad-product-team
  15. https://www.linkedin.com/pulse/20141007135229-1453794-5-symptoms-to-fire-your-product-manager