Monday, 22 June 2020

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.

Friday, 19 June 2020

BRIEFING: ThoughtWorks TECHNOLOGY RADAR Vol 22

Last week was the briefing webinar for the ThoughtWorks Technology Radar. Like many of us, this was the first time they had gone through a process remotely which appeared as the pun/theme "the elephant in the zoom". It is interesting to hear from experts in specific technology areas discuss the latest trends and techniques. This time I was struck by the story behind how the Tech Radar came about. 

It didn't start as a external "thought leadership" or sales device, It was a reaction to business growth and internal knowledge management issues. I think it's the bi-directional process of the teams feeding in the ideas, the advisory board then collating and debating them to pull out patterns and asses the different maturity levels makes it powerful. Also this is based on actual experience from their projects, rather than desk analysis that you might get from a report like Gartners.

They also offer advice on how to make your own, which is great to get people sharing experience and what lessons about work in an organisation. It's like harnessing the power of multiple retrospectives in an easy to consume format.

On the actual content, Some takeaways for me were the concept of GitOps and tools like Argo CD, who in their own words:

Argo CD follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state

The ecosystem around Kubernetes is developing rapidly, tools like this making visualise what is happening a lot easier during a deployment. The recommendation to adopt tools like Cypress and Figma both of which I've heard good feedback on. Figma in particular has been great with collaborating with a designer, and sharing with the customer, on a project that I've been working on this year.

There are also emerging tools in Experiment tracking tools for machine learning where like Argo CD, different domains are getting similar tools to more traditional code, it sounds great in reliably productionising models.

Friday, 1 May 2020

My photography workflow 2020

Setting up a "workflow" or an organisation to your work, is a key part of moving from a beginner to immediate kill and above. So a bit about my photography workflow since I am slowly retiring my old Mac Mini and OSX Snow Leopard and moving to an old Windows 10 desktop. Just before COVID-19 turned the world upside down I had also got a new camera not supported by any of the RAW converters I was using. 

Shooting


For my veteran Canon 450D I have a couple of styles setup from Cinescopophilia shooting RAW + JPEG. I have in the past sometimes shot RAW only, but it was a pain if software didn't support it. But now even my phone can process the CR2 RAW files!




On my X100 and X-T100 mirrorless cameras I have started to try and follow the tips from In Camera: Perfect Pictures Straight Out of the Camera by Gordon Laing with general settings from Fredrik Averpil and Film simulation settings on Fuji Weekly The X100 is also another veteran now, but being a premium camera when launched it has 3 custom settings compared to the newer entry level X-T100 that only has one setting :-(

The red thumb grips add a bit of bling and make the smaller mirrorless bodies a bit easier to use. As does the screw in soft release button on the X100. I also use my spare on my Grandad's old Olympus Trip 35 film camera.

Editing and storing

The biggest journey I have been on in photography is my technique around editing. I used to like DxO Optics and the very finely tuned body + lens corrections, but as a hobbyist it's a bit of overkill, the equivalent of a startup adopting the process a multinational needs. 

I have 5 key bits of software I use - RAW conversion to "develop" and polish photos. Library to store, search, and organise. Film effects to give a vintage look, if I'm honest usually to make up for errors in shooting settings ;-). HDR for landscapes or interiors with tricky lighting for a single frame to capture. Finally, Panorama stitcher for when I don't have a wide enough lens to do a scene justice, or to provide a much higher resolution image than I could with a single frame.


From;

  • RAW conversion: Digital Photo Professional (DPP), DxO Optics 6, Aperture
  • Library: Aperture
  • Film effects: DxO FilmLab 3, CameraBag
  • HDR: HDRist
  • Panorama: Panorama Maker 4




To;

  • Raw conversion: DPP 4, CaptureOne Fujifilm express, CameraBag Pro, Polarr Pro (also on Chromebook and iPhone)
  • Library: CaptureOne Fujifilm express
  • Film effects: CameraBag Pro
  • HDR: Skylum Aurora 2018
  • Panorama: Panorama Maker 6


The main switch has been giving up Aperture. It's a shame that Apple retired it, I plan on going back to Apple hardware once finances allow and trying out Gentleman Coders RAW Power as a successor to Aperture. I have been tempted by Lightroom at several points, but the relationship that CaptureOne has with Fuji plus some good reviews comparing them means I'd rather pay for CaptureOne Fujifilm. One minor faff at the moment is using either DPP or CameraBag Pro to convert my Canon RAW files to TIFF, so that I can edit them in the Fuji specific version of CaptureOne. I don't shot that much on it anymore, but I find as my skills improve I'm editing RAW files over a decade old!

Polarr Pro and CameraBag Pro are both good value Lightroom alternatives for the kind of photo editing I do. They also have free trials, so it's worth taking a look.

One addition to my workflow is syncing my output folder to Amazon Photos, plus manually backing up originals periodically. I used to copy all my iPhone photos into the same local file system on my Mac Mini, but now I also sync that automatically. Luckily the GoPro and Canon software can automatically pull photos off the memory card. They then go into source folders that Amazon backup is watching. The technology pretty much just works, and it is one less thing to think about.

Before I realised that Amazon photos stored uncompressed hi-res files by default, I was planning on using Google Photos to go alongside my Chromebook. I've used Picasa since before Google took it over and folded it into Google+, before a linkage with Google drive and then its current incarnation. It's slowly become less useful and if it wasn't a key consumer feature to have, I expect it would already be in the Google graveyard.

Having created order and a system with my photography has been oddly therapeutic. It's also a useful skill to practice! 

Sharing

This is one part that I am still figuring out. I used to use Flickr as my main way of sharing images, with albums on Facebook. Now I seem to be in a cycle of sharing an image (or small set) on Instagram. It feels like the community on Instagram is much more like the community of 2008 Flickr. I also have a small portfolio on GuruShots. So far from their competitions I have got photos that are going to be in exhibitions for galleries in Berlin, Stockholm, and Melbourne. For a hobbyist like me, it helps give inspiration and focus on what to do next.

Comparisons of Lightroom and CaptureOne

In case any Lightroom uses are interested in jumping ship. Lightroom seems to be the "average" RAW converter these days - not the worst, but not the best either.

Wednesday, 29 April 2020

Using RStudio with a Chromebook

Given my interest in using R as an analysis tool and using a Chromebook as my main laptop at home and on side projects for 2 years, thought I'd take a quick  look at some options for combining the two.


Option 1 - Using RStudio on AWS


This has been my main usage of R at home, using RStudio on Windows 10 at work. With a couple of preset images created it's easy to get up and running. I used the image created by Louis Aslett. There are a few alternatives around now, even the Amazon have an article that goes into a bit more depth on Running R on AWS. THis allows you to fine tune what is setup. I have been using this for about a year now and the experience is so seamless on a Chromebook, since everything else is also running as a Chrome app.

Pros: 

  • Use computing power in the cloud, can easily share
  • Consistent experience no matter the computer you use to access it

Cons: 

  • AWS management consoles do have a learning curve
  • Small monthly charge for storage option in the image

Option 2 - On a Chromebook directly using Linux beta

This is one of the newer options. I used Mark Sellor's guide to getting started, although I downloaded the Debian package directly from the RStudio website and needed to run 


sudo apt install libnss3

as there is now a new dependency. One of the surprising things for me about this process was that I remembered how to use Vi well enough I didn't read the instructions until I had already edited the file. 

Pros:

  • Offline access to an R environment, on the go
Cons:
  • Most Chromebooks are under-powered, so not useful for any heavy data crunching!
  • Bit effort/familiarity required with Linux command line

Option 3 - In the cloud!


One of the more exciting options is the new https://rstudio.cloud/ as the name suggests this is a hosted version of RStudio in the cloud. Similar to the AWS option but even less to worry about. I created an account using my GitHub credentials and then imported a project from GitHub and was up and running. No setup that isn't directly related to the code that you want to run. Nice tool-tips that prompt you to install required packages that aren't already in your workspace. Not surprised how well this works given RStudio has had a server version for years, this probably gave them a head start over putting a pure desktop app.


Pros:
  • Really easy to use
  • Hosting all taken care of
  • It's still in beta - so no cost yet

Cons:
  • It's still in beta - so potential disruption to service

Option 4 - RStudio Desktop/Server at home


Speaking of RStudio's sever version ... I have recently rebuilt an old PC for my photography hobby editing. This includes an NVidia graphics card that could also be used for some GPU acceleration, for example TensorFlow for R, if I just use that :-) I think from looking at the three other options, now I have a more powerful setup this will be the most straight forward option! I'm keeping an eye on RStudio.cloud though, as it does save the overhead of version management.

Some of my adventures to date

Wednesday, 11 September 2019

MEETUP: Discovery is a mindset not a stage - creating a learning organisation at ProductTank Brighton

Last night was the latest installment of ProductTank in Brighton. We were lucky to have an overview of continuous discovery from Teresa Torres.

She started off by discussing how discovery and delivery should be more intertwined and not separate phases - this can be a problem with “dual track” as it can be impression it gives. She then asked "Continuous discovery ... are you really doing it like this?" Or is it research with a project mindset?

Getting better week after week



The question to guide setting up product discovery is “How do we get better week over week”


We make product decisions every day, so if we want to be truly customer centric then we need to engage with our customers every week so that our decisions are infused with their input. Need to avoid cognitive bias because we are thinking about product all day every day, check the decisions with what our customers expect. 

Shooting here for co-creating with a product mindset. Otherwise you can drift into a project mindset by developing in a vacuum, then asking customers to “validate” with a short gap between delivery into engineering. The earlier you get feedback the easier it is to change and the more likely you are to do it ... and not rationalise away what you need to change. 

This is not to say customers dictate solutions. We are experts in that. They are experts in their context and problems. This is where we Co create. Two sets of expertise becoming more than sum of their parts. 

She then gave an intro to "Opportunity solution tree" - for more details I'd highly recommend her post that goes into how to build one up.

The key is to create one opportunity tree to target one quantifiable metric. The goals is how we must best achieve a business outcome. Then map out customer needs that we think will drive opportunities will meet that need, and the solutions that deliver on that goal. The goal should be a two way negotiation between product leader with the team, leader to set business context etc and the team to communicate how soon/feasible. 

Her final tip was when interviewing get them to tell stories - “tell me about a time when” - as it is a better method of collecting insight than how/where/when questions that can be leading. She also recommended starting off every customer contact with this kind of question, before then getting feedback on a specific slice on functionality. To make sure that you gain the generative feedback without leading with your assumptions. 

Further reading


Sunday, 7 October 2018

Adventures with flow and transparency

Photo by Sasha • Stories on Unsplash
This is a follow up to my post on roadmaps and themes. I wanted to talk about experience in a B2B context with a platform product and SaaS-style model a bit more. Most articles out there tend to be from B2C or app products.

So about the time I wrote about theme based roadmaps, I was using a combination of spreadsheets, Trello, and JIRA ... all OK for their intended purpose, but all have limitations around use and structure for product people. 

Limitations that possibly are blockers in increasing flow and transparency in the product development process. So, why are flow and transparency important? I think this tweet by John Cutler sums it up



The flow aspect allows feedback and course alteration as new info is uncovered. The transparency aspect allows those that can input be part of the environment that you are creating to make better decisions.


So what do I mean by "flow"

To me it means having a regular and consistent progression of work through to delivery. It means not working towards an arbitrary release date. You have a light enough touch process to deploy through to production without much overhead. This implies having skill and discipline across the team in chunking up issues, to a minimal size, to flow through the system. For me, this was a natural transition from larger platform pieces tied to a theme. Then switching to unlocking the capability that they made available with smaller experiments.

It also means that you need a good understanding of what you are aiming for, to guide the smaller pieces of work and not get lost. To do this I needed a good picture of our options and feedback. Using a combination of spreadsheets, Trello, and JIRA was making this difficult.

Building foundations

The first step was to get ideas in one place, with customer feedback logged in same place to link to the ideas and build up picture of the need - with ability to  share with the team!

This become the place to start to flesh out ideas with high-level problem and value of solution if delivered, much easier to connect the dots. There was also an added benefit - the designs, user stories, and specs can all be held in one place prior to pushing to development management tool, e,g. JIRA, and results of spikes can form part of the idea.

Also now the data is more explicitly structured I can report on it - and daily/weekly emails can help communicate team activity

What happened next

Once all the activity was in one place, organised to try and explain what was going on and available to query on-demand. I learned three lessons:

First, people naturally want to help, but they won't be aiming for your goals or fully aware of your job role. I.e. they won't be doing your work for you ... so, you need to understand what drives them and where common work can help. Then use that for mutual benefit. One barrier is using a different system, so auto updates between systems, or simple logging of interactions, can ease collaboration. 

Secondly, flow has benefits is lack of management overhead needed in coordination, but unexpected events can through it off. E.g. a backlog in process can have a knock on effect that over time causes greater coordination to get momentum back. So, keep an eye on your delivery metrics. Not as targets, as they'll then become vanity metrics, but to track the health of the system. Dashboards that show trends are great for these.

Finally transparency is important for trust, but ensure that your audience understand what you are communicating and why. Be careful of inadvertently over-promising. One area of misunderstanding that can arise here is the different between a roadmap and a release plan.

Thursday, 23 August 2018

Returning to code, worth it for a Product Manager?

The past couple of weeks have given me opportunities to reflect on what I like about my job and previous experience. Partly because we are expanding the team at 15below, partly from doing a bit of coding. I have written a bit about becoming "post-technical" in the past, but now is the first time I have done much code in years.

The thing that I enjoy most is solving problems and helping people. Throughout my career solving business problems to help create positive outcomes has always been fulfilling. Now I get to help do that, then go back and refine the solutions. You don't always get to do that as a developer or in a project focused role.

Side project

Code wot I wrote
The first bit of coding is on my side project. Martyn has created a great architecture and I contributed the project import from LinkedIn (almost) all by myself. It feels to brilliant to code on a side project - you get a sense of achievement from seeing an idea come to life. It also provides a way to express ideas and a method of  collaboration. It's easier sometime to do some rough code and then hand over to a proper developer to complete. It also helps that Elixir is a nice language to use, and reminds me of Prolog.


Work

The second bit of coding recently has been creating a report for work. Slightly different motivation here. I needed some information to share and the developer resource to surface it was better used elsewhere. I had just enough skill to self-serve the report creation and I was still exploring what was interesting and tweaking how the data was tagged. So, it was much simpler for me to prototype what I needed. Once this has stabilised then I expect to handover to get integrated fully into our MIS reporting.

It has been fun using the RStudio environment, again with a nod to previous experience this time Matlab, although the language is different. I have an environment in an AWS instance that I can access via the browser on my Chromebook, and an install on my Windows laptop.


Should Product Mangers code?

At the same time all this was going on, a blog post answering the question "Should product managers know how to code?" popped up. I must admit, my heart did sink a little to see what that might contain. However, I was pleasantly surprised. In particular the tip it gives about learning some CSS and exploring  ‘Inspect Element’  to tweak pages and see how changes will look. Also learning what happens where in your application is a good idea. The best people I know that work in non-technical roles in software understand this.

So, although it's fun I don't think Product Managers need to code. It can be useful in understanding. Or self-serving for quickly prototyping ideas.

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/...