Part of the Process

Last week was an interesting edition of the ProductTank Brighton meetup hosted by Pure360 . The topic was " Product Management in Unusual Places ". Reading blogs and books it is easy to think that Product Management falls into two distinct groups of "B2C" and "B2B". Yet there are some more interesting cases lurking in there. Faye Wakefield from Comic Relief started with a talk on "When everything MUST be alright on the night, how do you test, collect feedback and iterate?" . Her situation is unusual as the focus for the year is pretty much on supporting seven hours of television once a year. Most of the donations come during this time. The key goal is to collect donations so the culture is risk averse in experimentation. S o this is an extreme environment for risk appetite. What was similar here was small user base interacting over time a large period of time. This is not suitable for doing A/B tests, or other experiments, to discover how to i

In this post, I'd like to make a short plea for better product documentation. One of the entry points to the Cronofy API documentation has an explicit link "for Product Managers". This link takes you to their use cases page. Over the past few years, I have looked at plenty of API documentation. From PDFs to the current trend of a GitHub repository and wiki. This was striking in how unusual it was. But if your product is an API then why should it be? In the technology service industry should we go further? Should there also be a "for testers" link? This could be like the Cronofy Product Managers link. It could reuse existing information but highlight and target them for a specific audience. For example, take the developer sections about rate limits and validation. Then add testing tips about your API for integration testing. Stripe has good developer documentation . Yet you have to scroll down a couple of pages of information before reaching the words "

Photo by Sebastiaan ter Burg So having a good roadmap with themes it is now important to get the work delivered somehow. Unless the developers have done something similar enough before. You need some way of discovering how to chunk up the work. What you call this doesn't really matter, but I have used the agile term "spike".  According to a comment in the Agile dictionary , this is a rock climbing term. A spike is driven into the rock face to help support the climbers. Although it does not get us closer to the top it allows us to go faster and have a safer climb. Likewise, a development spike doesn't produce the feature faster, but it provides a foundation to move forwards. In a project kick-off meeting, I remarked about how successful the spike had been. A developer there joked that I should write a blog about it, so here it is... "challenge accepted". I have been reflecting on what I feel made the spike successful. This particular

The wrong kind of roadmap... This post was inspired by a chance conversation from a developer, from another Brighton based software product firm. This occurred during The Lean Event . The conversation started during an audience participation section of Jared Spool's talk . I told him about trying to organise around themes and in exchange He told me about a lack of connection without that. This pleased me as it meant I was on the right track, but also reminded me not everyone has it sorted ( even if you think they do from the outside ). Unknown to me at the time I was sat at the table with Roman Pilcher! (more on him later) In the past three years there have been three big influences on the way that I look at roadmaps. Well that and software development, they are (in chronological order): Gojko Adzic introduced me to Impact Mapping at one of the first Product Owner Survival Camps.  First we learned about the importance of goals. Then being able to measure the impac