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.

Comments

Popular posts from this blog

CONFERENCE: TTI Summer Forum 2017 – Getting to Grips with GDPR

On HBX and online education

On performance and environment