MEETUP: "Collaborative product management " at ProductTank Brighton

Looking at my notes I forgot to blog about November's meetup "From Startup to Corp: The differences, and how to adapt to the change." sponsored by 15below. There were three very good talks on the difference between very small companies and massive ones. Some highlights from the three talks:

• Don't feel like you have to aim for moonshots if you aren't Google Ventures - you only get a limited number of bets compared to GV, so a 10% incremental improvement every year is nothing to be ashamed of!

• Don't feel too embarrassed by your peers - if you start of at the same time as JustEat but have a much more niche market it's OK to have more modest growth.

• Just because you can see everyone doesn't mean that they know what you are doing - large organisations have the privilege of knowing communication is poor so actively do things to encourage it, in a small startup you have to make ensure people are informed.

• Large organisations can offer more support and flex around you - for example cover maternity leave or secondment to another business unit.

But anyway ... last week was another interesting edition of the ProductTank Brighton meetup hosted by Rakuten on "Collaborative product management".

Unfortunately, the first speaker scheduled - Dan Kidd - couldn't make it to deliver his talk "Now That's What I Call Continuous Delivery". I was really interested to hear how madgex have used the improved feedback cycles. I am looking forward to the reschedule!

Instead, the first talk was by Ed Vinicombe on "My three critical values of collaborative design" and how traditional ways of working are changing in knowledge work. He is really lucky at UXClub.com to be guided almost entirely by user research (and not HiPPO!). It sounded like this gave him the freedom to collaborate around the requests and deliver quicker.

Next up was Mike Rowlands talking about the development culture at LShift. Maybe controversially for a Product Managers meetup he was suggesting that the role might not be needed! They had very deliberately set out to recruit senior polyglot developers. Ensuring that they fit working as lead developers in an AgilePM environment. Both the team sizes and projects undertaken are kept small. It is up to the lead dev to choose the appropriate tool for the job and peer review is used as a check and balance. They work closely with the clients and do a lot of the communications without an intermediary. This collaboration between client and dev is what helps develop the product. I can see how in this specific environment it works. As it is appropriate in consultancy style "products", but I'm not sure it works as well for long running commercial off the shelf software.

It was interesting hearing from an MD who had created the kind of company he wanted to work in and vigorously defended that culture as it expanded. It sounded like being careful at the type of work accepted played a key role in this. A final little tip was that they aimed to get the work completed and handed over so the clients could support their own BaU operations. But the clients in most cases kept them on support contracts because of the way they solved problems in a transparent manner.