CONFERENCE: SofaConf2020 - Day 1 - Product stream

First day of a new conference - SofaConf 2020 "A stay-at-home conference" - that came about in reaction to COVID-19 and lockdown/travel restrictions. Overall very good content so far, lots of sessions that speak to real issues in doing product development in the real world. Slight technical issue with quality of Andy Budd's broadcast that was quickly sorted.

The Secret Weapon to Finding Focus - Melissa Perri

Melissa explained the build trap, where features are not seen as "what is the business value I want to provide" but rather "here are some features we want as  output".

Netflix realised that they were in the build trap with Roku, and getting into competition with hardware companies that they could partner with. So they spun it out and so that they could then double down on their core competency.

Now is the time to focus, what can we do to win? .... first you need a good product Strategy framework. alignment builds autonomous teams. The right level people should be focusing on the appropriate tasks

I was thinking that delivering one thing but not delivering 5 things isn't as painful as not delivering 6 things.

 A great quote that came out was "in times of crisis the companies that focus will win". If you don't have business goals from your leadership then set your own success metrics and keep to them, keep talking about them, slowly nudge the business into focus around the same business goals (bonus: if they aren't the right ones then it's a prompt for the leadership team to correct them and share the more concrete goals)

The build trap can come from leaders thinking the come up with ideas and then team delivers them. If you want the leadership to change then you need to change. Following on from the above, ask more questions around what they think building that feature will deliver, if it is successful then great ... if not then ask what can we do differently to avoid that wasted effort? 

Related to the discussion that came out of the QA around the build trap and senior management handing down ideas to deliver, David Hughes shared a link to Is It Real? Can We Win? Is It Worth Doing?: Managing Risk and Reward in an Innovation Portfolio in HBR as a structure to help get focus around goals and ensure the teams aren't being spread to thin.

Outcomes Over Output - Josh Seiden

Josh started off saying that we often don't have shared crystal definition for "outcome" and the closest we get is more like "result" ... But it should be more like a "change in human behaviour that creates value". The problem with output and "done" is illustrated with this quote from the website for Managing Outcomes

When is Microsoft Word done? When is Google done? Or Facebook? In reality, software systems are never done. So then how do we give teams a goal that they can work on? 

For example, There can be nothing wrong with output - on time, on spec, on budget ... yet outcome can be a failure! Illustrated with a road planning example where they were trying to make streets safer, they choose to do this by putting up street signs to stop people taking left turns ... but they kept taking left turns

  "Products Create behaviour", we aren't looking to create street signs, we are looking to stop people taking left turns. e.g. see my favourite saying in this area "True Innovation Comes With Changing Human Behaviour" 

 

Trouble is that most products are part of complex system that include the users, e.g. most twitter features we see as core came from user behaviour from people using the system. Or Instagram tagging has lead to certain locations to become overrun with people looking to get great photos based on others they have seen at the same location, so a national park in the US put out an ad asking people not to use specific location tag but a generic one. So there is a feedback loop that includes stakeholders outside the companies producing the products or their users.

Finally Josh touched on anti-racism issues that are in the news at the moment, and how this has caused some self-reflection in making sure that our product, policy, and system design aren't just not accidentally racist but actively anti-racist. In the discussion Simon Pearson shared a toolkit which helps look at potential unintended consequences of product building, which is worth a look: Consequence Scanning

Advanced Facilitation: Using A Designer’s Toolbox To address Organisational Strategy - Haroon Aslam

Unfortunately I didn't catch as much of this talk, but I think it can be summed up in these two slides. The "before" is the design equation and the toolkit of a designer, when applied to customer projects and products. 

Compared to the "after" where you apply those tools to your org design

Haroon went through the usual facilitation process and highlighted the differences and things to look out for when doing this, as you are now part of the same org and don't have that same neutrality from being external. The top three for me were:

• When collecting and navigating conflicting sources of truth 
• What smart questions can you ask to show that you are open to learning?
• Be mindful of tone and energy in the room, don't let perfect be the enemy of good and keep moving forward to get decisions 

Healing The Designer/Product Manager Divide - John Cutler

John gave a really insightful talk on why developers and designers can started to question what the product manager is for and ways of working. He then talked through the North Star model, being a persistent mental model rather than work based one, can be applied to help design a solution to the problem. 

Using this "North Star" process with one pager to build alignment with designers. This avoids prescriptive OKR and KPIs to give a unifying direction, which the product managers and designers can get behind. Really summed up in this slide ...

... get alignment about why the project is going ahead first, to help make it easier when you get to the what and how.

One thing that struck me was the idea of creating a learning backlog, for the Product Manager to ask the team "what would you prioritise to learn about with this new effort?". In the past I have put larger spike tasks near the beginning of a project, but that is a bit of a "small chunk" waterfall approach, it makes a lot of sense to me to break down the learning and change direction as you learn.