Product Management with Niel Robertson
Update: Changed Project to Product, I didn’t realize the differences. Niel pointed out that they aren’t the same in another thread.
Niel sent the actually Power Point which you can check out for yourself, product-management-v1.
We have met with Niel Robertson before, but this was the first time we got to see him present a topic. He gave a talk at TechStars informing groups why Product Management (PM) for startups is important. In fact, he went as far as saying the number one thing that goes wrong at startups might be PM. Niel described PM as a process for delivering the right features at the right time. He went on to discuss why PM can become stale, be ignored, and is often hated because it is associated with excessive documentation, which it shouldn’t be. Mentioning more than once that the best feature requests, requirements, and specs are often just one sentence.
Niel presented PM as a general evolving process, and specifically avoided specific PM systems or methodologies. Niel said he is totally document agnostic and all systems have positives and negatives in terms of PM. It came across that it wasn’t important what system was used, but that everyone at every stage of the project must write things down. He described that ideally every test case should be tied all the way back through spec, requirement, and finally feature. One thing that Niel specifically did say was worth doing was completing a feature review before QA. Have an engineer walk through the project and show each of the requirements being fulfilled, have the product manager and QA lead attend this feature review.
His basic points about why every product can benefit from PM are:
- It takes 30 secs to write a requirement
- 2 minutes to clarify in discussion
- 5 min to for an engineer to spec
- Hours or days to prototype, write code, integrate, or deploy it
Because of these points he doesn’t want to hear a team is small and agile so following a PM process would slow them down. In the long run following a process will be faster. That point really hit home with a concrete example he gave, “If a project is UI intensive absolutely do not start coding, go to a white board.” This resonated with me, because we made a huge mistake with my last startup, by getting into the prototype without spending enough time thinking about UI. He said, “Don’t tell me that product management is something you do at a bigger company that has more complexity.”
As my notes are often just a list of key points that caught my attention, I will do as I often do and share some favorites.
- How to write a good requirement… “The user should be able to…”
- How to respond with a good spec… “The user can do that by… doing X… List the exceptions”
- A spec is well written when QA can figure out how to test a feature based on the spec.
- Doesn’t encourage people to shotgun tons of things to market. “When I make spaghetti, I try not to throw all of it against the wall.”
- On gathering data, go out and talk to people getting more data points about the problem you are solving until you start hearing the same things and can’t learn more from talking. Then go work on it, knowing all this data.
- Niel doesn’t recommend a developer also taking on the role of PM, as there needs to be a tension between who represents the user and who implements the product.
- “The PM should be the most empowered employee in your company… Yes, even more than the CEO”
There were a ton of other good thoughts on what exactly a PM does, and how to select a good PM, but as always I can’t really do a presentation justice. Thanks Niel for the great talk.