Author Archives: Annu

Three questions for product manager Roger Cauvin

Roger

Product Mantra: What prioritisation technique(s) would you use at a startup where product users are both internal and external?
Roger Cauvin: Product managers should build consensus with every member of the product team (including internal users) for a focused value proposition that keeps internal users and stakeholders aligned with the needs of the target market and with the product’s positioning. This sort of product strategy consensus enables all team members to execute cooperatively and to set aside personal preferences in deference to delivering the promised value. I recommend composing a competitive mindshare map to position (determine the unique value proposition of) the product.

The team should agree to consider every product decision in terms of the extent to which it supports the unique value proposition.

Some practical ways I’ve used to build this product strategy consensus include:

* Walk the team through the competitive landscape and positioning represented in the competitive mindshare map.
* Interview prospects and share and review the interview notes with the team.
* Compose a slide deck of buyer and user personas and review them with the team.
* Compose a lean canvas and review, in particular, the “problem” and “unique value proposition” sections.
* Take every opportunity to relate product decisions, requirements, and design back to the unique value proposition.

Product Mantra: What advice do you have for a product manager in a startup who is expected to do more than just product management?
Roger Cauvin: Depending on the situation, responsibilities outside the strict product management role may represent a personal growth opportunity.

For example, I ran product at a startup that lacked the resources to hire a user experience designer. Consequently, it became my responsibility to design the user experience for an overhauled version of the product. I embraced this responsibility as an opportunity to learn user experience (UX) patterns and practice mocking up user interfaces.

Simultaneously, however, I educated the rest of the executive team on how user experience is not part of the product management skill set, and how a dedicated user experience designer would likely produce a higher quality design in a more timely fashion. They agreed and were prepared to hire a user experience designer once the budget allowed for it. (Unfortunately, our funding ran out, so we were never able to budget for it.)

Another avenue worth pursuing is to identify colleagues interested in carrying out the responsibilities and empowering them to do so. In startups, we all have to be prepared to be fluid in the roles we play to work as a team to deliver the best business outcomes. That burden shouldn’t lie exclusively on product management. At any particular time, for any particular job to be done, the team has to identify the people best suited to take on the responsibilities.

Product Mantra: How would you go about introducing lean startup techniques at a startup?
Roger Cauvin: First, compose a lean canvas for your product(s). No excuses. Just do it. It’s a quick way of being explicit about your product strategy so you can begin testing the hypotheses and iterating on them. I suggest composing it in Google Slides so that it’s accessible from all devices and simultaneously viewable and editable in real-time by all team members.

Second, make sure you are interviewing and observing prospective buyers and users on a fairly regular basis. If you can’t tap into the sales pipeline to identify prospects, think creatively about your own network of friends and professionals who could connect you to prospects that may not be on your company’s radar screen yet.

Third, identify the metrics that matter and start tracking them. You may need to work with marketing and/or sales ops to gain access to the tools you need, such as Google Analytics or Salesforce.

Fourth, instrument the product(s) to track usage. Tools such as MixPanel enable you to track not only events and page views, but also “funnels”, which are sequences of events that comprise a use case. I recommend documenting the key events to track in Google Sheets. For web-based applications, developers can implement events by inserting simple snippets of Javascript.

Finally, you can build consensus for lean startup approaches by educating the team about them and their benefits. Start with an introduction to lean startup and follow up by posting and walking through a model of lean startup concepts.

Practices for a learning product manager

There are some key learnings for product managers from Peter Senge’s ‘The Art and Practice of the Learning Organization’ and lean principles. I have extracted three of them and their applications to product management here:

  • Keep away from “I am my position” syndrome
    This is has been identified as one of the learning disabilities in organizations.“When people are asked what they do for a living, they often describe the tasks they perform everyday, not the purpose of the enterprise of which they are part of. Most  see themselves within a system over which they have little or no influence.

    A product manager must not take this standpoint especially because one has to work across organizational boundaries to achieve success. Focusing only on your position and protecting it does not result in a great product. A product manager has to feel a sense of overall responsibility for the results produced when all positions within an organization interact and be a catalyst in enabling these interactions.

  • Be very slow to judge
    Each one of us has a tendency to blame someone else when something goes wrong, this begins in our early years in this world. Its most common form in organizations is when one department blames another. A product manager who exhibits ‘I am my position’ syndrome often fails to see how his/her actions extend beyond the boundary of the role. Each person’s actions has consequences, and these actions often do come back to hurt us, and very often these problems are perceived as externally caused. People’s behavior is based on the the system they work within, this means we must be slow to judge. There are some complex dynamics in workplaces.
  • Understand overburden produces waste
    It is common for customers to apply high pressure when it comes to release dates, and the easiest thing to do is to pass this pressure straight down to development. Who does development pass on the pressure to? Code of course, developers perform some quality-destroying shortcuts and introduce technical debt into the system. A short-term goal maybe achieved e.g. deadlines for current release is met, however future releases slow down and the pressure is on again and this visious cycle continues. Overburdening developers results in quick gains that may seem fine at the outset, but introduces waste in the future.

A healthy product development process

Below are some of the characteristics that are important for a healthy product development process:
  • Adaptability
    A good product development process is adaptive. The basis for this is users often don’t have a clear understanding what he/she wants until given something tangible. Once presented with a something tangible, we can learn which elements are useful and which are not. It is impossible to guess which elements are the most valuable. We learn from users actually using the system and ideally should be able to apply this learning quickly.Adaptability is not easy especially when executives and business desire predictability. This is especially so in large organizations as every department is expected to working according a plan. Predictability and adaptability are at odds with each other.  Predictive processes measure success by conformance to a plan; adaptive processes measure success using various customer feedback mechanisms.
    • Ability to deliver fast
      The ability to deliver fast is one of the key principles of lean product development.
      “Think of reliable, repeatable, rapid delivery as a sign of excellence in a software development organization.” Mary Poppendieck
      Fast delivery is sign of good, solid engineering practices and a mature software development organization. Examples of practices that enable fast delivery:
      –       immediate clarification of requirements
      –       no time-consuming handoffs
      –       minimal delays in testing, integration
      –       daily builds and rapid feedback from integration tests
      Fast delivery encourages an organization to take an experimental approach to product development; team members are encouraged to try out new ideas and learn from real user feedback instead of building a product based on assumptions.
  • Information flow
    There should be free bi-directional flow of information between the various departments within an organization and that too with minimum delays. Emphasis on  documents and passing it ‘over the wall’ is less than ideal; it contributes to waste and loss of tacit knowledge. The most effective mechanism of communication is face-to-face communication. The boundaries that exist  within organizations are often barriers to information flow and can contribute to loss of customer affinity.