Roadmap elements

This is a write-up of a discussion the UK government’s community of product managers held to agree which elements are important to include in our product or service roadmaps.

We think it’s worth agreeing these elements so that roadmaps are consistent and can be understood across our organisations, regardless of who’s looking and where they are viewed.

The elements are being posted here to invite comments and suggestions before being published as guidance on the Service Manual.

***

A. Products should be judged on their delivery of value to users. Roadmaps are a tool to express what the value of a product will be and how that value will be understood and released in stages.

B. Each product has its own roadmap, or is represented on a roadmap providing a collective view of products related to a service. If user needs call for more than one instance (eg. simultaneously on a wall and one online), every version of the roadmap must be kept in sync.

C. Roadmaps are developed iteratively and regularly. Creation and iteration of a roadmap is a collaborative effort led by the product manager with the delivery team, stakeholders and the product’s users.

D. The roadmap is open and available in the public domain (unless there is a very good security reason not to).

E Roadmaps use simple illustration and plain English to provide information. This makes it easy for anyone to pick up and quickly understand how and why the product is being developed. They tell people where else to go if they need additional in-depth information (such as a product backlog or blog).

F. Roadmaps are framed by a vision explaining the ultimate outcome a product is trying to deliver. The roadmap is broken down into objective-based missions, each of which gets us closer toward achieving the long term vision.

G. Missions are outcome-based objectives with an explanation of what the goal is (often a problem to be solved) and how progress will be measured. Agreeing these missions involves conversations with users, the organisation’s leadership and the team doing the delivery.

H. Missions are mapped over time (eg. quarters). The segments of time on a roadmap are consistent. When the roadmap contains phases (such as discovery or beta) these should be timeboxed.

I. Roadmaps show what’s been done and what is coming next in order of priority. The method of prioritisation is transparent and consistent.

J. Roadmaps enable us to plan for change. They capture intent, not solutions. The further in the future a mission is, the more uncertain it is. The closer the mission gets, the more is learned and the more confident we become that it is the right thing to work on. Things can be dropped from roadmaps.

K. Each roadmap provides an explanation of who it’s for, how to read it, who maintains it, how often it is updated, and how to contribute to its development.

L. When roadmap software is used, the content should be exportable (preferably via API) to enable reuse.

Product Manager or Product Owner?

In government, in practice, they’re synonymous. Because we care more about the responsibilities than titles, right?

But sometimes it’s a thing for some people. They raise it as if to suggest it’s an unresolvable ‘chicken or egg’ type of question. This is how I explain it.

In GDS we use Product Manager.

We don’t think Product Owner is wrong. Product Manager is just more us.

Product Owner is a Scrum thing. Like Scrum Master is a Scrum thing. We like Scrum but it’s not the only method we use. We want the people managing our products to be able to use a range of delivery methods. So using Product Manager is a signal of intent.

Product Owner is a term that’s used less frequently than Product Manager. It makes sense for us to use a title that people relate to when we are trying to attract the highest number of quality candidates to product management jobs in government.

Search trends for ‘Product Manager’ vs ‘Product Owner’

Worldwide results for ‘Product Manager’ jobs on LinkedIn

Worldwide results for ‘Product Owner’ jobs on LinkedIn

Product Manager is used by the majority of government organisations. And when digital, data and technology people from across government got together en masse recently to agree the roles and responsibilities we need to deliver better services, we settled on Product Manager. By saying ‘the majority’, that’s acknowledgement that the agreement is new and taking some time to percolate through.

Where it gets a bit confusing is in a few departments they have Product Owners and Product Managers. In these cases the Product Owners come ‘from the business’ and don’t have product management responsibilities. What they are is subject matter experts, who are very welcome helping delivery teams to understand the policy and operational realities. But we could be doing with calling them something else. Maybe just referring to them by their actual policy or operations role titles. That would make things clearer.

Fundamentally role titles evolve. We should hold onto them loosely to protect against hubris.

What we must spend more time and effort on is making sure that when we configure teams we give people a combination of responsibilities that are compelling and commensal. Google it.

Another tour of duty

I’m finishing up at MyGov and the Scottish Government’s Digital Directorate. It’s been a short gig but it’s been well-played.

Scotland’s is a digital future

I am pleased to have had the opportunity to represent MyGov. I’ve done my bit by negotiating the team through a period of intense pressure while also bringing longer term stability to the resources in the programme, and mapping out an ambitious roadmap for future delivery.

My decision is not a reflection on MyGov. I believe in the mission and I especially believe in the team. You have a huge amount of talent; you are going to continue to make awesome products and services for Scotland, and make people’s lives better as a result of your efforts – of that I am certain.

You are a resilient and self-supporting bunch, plus you have great leaders in Colin, Graham and Rachel, who will ably see you through this period as you stand up beta.gov.scot and begin developing mygov.scot again with gusto. And then there are the new starters lined up to join the team, who will complement your abilities and effort.

I’m not leaving government and I’ll remain a strong and active supporter of MyGov.

Back to the future

I’m really pleased to have been invited onto another tour of duty with the Government Digital Service. This time around I’ll be serving the community of product and service managers in GDS and around government in the UK – helping them to stay connected with one another, share their skills and get people excited about their craft.

I’m ridiculously excited about this new role. I’m looking forward to being back with old colleagues of course, but 3 years is a long time to be away and I’m even more inspired about working with the new guard there. There is so much energy in this new era for GDS and the challenges are compelling.

It feels like a good time to be going back to something different.

More on that anon.

Thank you @mygovscot

For the time being, it’s thank you, goodbye and good luck to my colleagues and friends in the Scottish Government.

Continuous improvement as a product manager

Continuous improvement – it’s the way to develop products. It’s also the way to be a better product manager.

I spend more time recruiting and directing product managers than I do being hands on with products these days. But because I love my trade and want to be the best coach that I can, I am always trying to up my game by learning new things.

Here are three ways I’ve been trying to improve as a product manager recently:

Better the devs you know

I am a product person who appreciates programming.

If I have a better understanding of the developer’s craft then my product vision is optimised, my explanation to the engineering team is more articulate and my appraisal of their efforts is better judged. Surely.

To that end, I’ve been steadily working my way through Codecademy’s courses, and by way of revision I’ve installed some of the Sololearn course apps on my phone, which are a better format for the commute.

Don’t send me your pull requests anytime soon. But it’s definitely broadened my thinking about the art of the possible… and the trade-offs. And it’s good to look at a team I work with everyday and see them in sharper focus.

The Jobs at hand

Ever since I started working in product management, it’s involved user stories.

And that’s been going great because user stories place more importance on the task someone is trying to complete when they are using your product than who they are or what my business’s requirements are.

But I’ve been hearing more and more about Jobs-to-be-Done and its application to product development, and I’m intrigued. It might be that ‘Job stories’ offer an even more relentless focus on what someone is trying to do and what their motivation is than ‘User stories’.

It might be that it’s time to make a switch or maybe there’s room for both in the mix of techniques I can use to make sure we are meeting user needs.

I’ve started asking my product managers to explore the possibilities of Jobs-to-be-Done, and Intercom has recently released a book on how they made the switch from user stories, which reads as a good, thorough introduction.

What a release

I’ve written a lot of release notes but I have started reading a lot as well.

It’s really easy just to hit ‘update’ and ignore the release notes; even easier never to acknowledge that release notes might be a thing produced for the service you use. I suspect that release notes are read only slightly more often than updates to T&Cs.

When you start to study release notes, you see there’s more variation between them than you’d first assume. Technical. Conversational. Brief. Detailed. But you can tell the difference between good and poor, well judged and lazy. Good products ought to have good release notes but not always.

I’m going to keep a book of examples, learn from them and see if we can get more users to take note of our release notes and use them as a means of engaging in a dialogue about what we’re developing and why.

Three improvements on before. But there is so much more to do. 

End note – Keep being ambitious Bath

This post was first published on the University of Bath Digital blog http://blogs.bath.ac.uk/digital/2015/12/16/keep-being-ambitious/.

On December 17th I will be saying goodbye to the University of Bath.

My move obviously creates a number of changes in the Digital team. But the central message is one of continuity. Improving digital communication remains a priority for the University, and the central team has the expertise to deliver on that goal. Leadership of the team and its projects will be provided by Phil and Rich, who are stepping up to head the team as an already proven partnership.

This is my opportunity to say a massive thank you to Bath Digital team – you are awesome and there is much to be proud of in terms of achievements.

Delivery is the reward

Digital is a team with a culture and track-record of delivery. Each member of the Digital team has committed to a set of delivery principles. I set high expectations early on and the team rallied. I think there are few challenges that could be put in front of this team that would overwhelm them.

It has been very satisfying to see the values and capability take root. I am proud of every individual team member for taking collective responsibility to transform what the University is capable of achieving through digital media.

Meeting the need

Our number one Delivery principle is ‘Put users’ needs first’. This principle has been transformative for our team as well as in many areas of digital publishing and service delivery around the University.

We now work on the basis that what’s best for our users is what’s best for the University. So when we are designing, developing or creating content for bath.ac.uk, our users and their need for fast and simple access to information and tools are informing and motivating our every move.

Getting time with users has not been easy but the team has worked and worked away to ensure a steady stream of user insight through interviews, analytics and feedback mechanisms. For me the extent to which we engage with end users mark us out amongst our peers.

Agile for real

We are now a team that uses agile development methods to deliver our work without skipping a beat. It all started with a two-day cross-functional sprint to create a site to welcome our new Chancellor and we have come on so far that we have been invited to coach others in the use of these agile methods. Even still we remain avid students and are always looking to learn and improve.

Agile is embedded across our content, design and development. You can see it all the way from our morning stand ups through to our sprint retrospectives. Establishing agile methods of working has brought structure and flexibility to our delivery and allows Bath to build world-class, user-centred services quickly and affordably.

See through

I think it was unfair but at the time I joined the Digital team was described by some at Bath as an inaccessible ‘black box’. One person’s perception is another’s reality and the situation today could not be more different.

We run weekly new work triage and scheduling sessions, blog about our output at the end of every sprint, we hold a fortnightly Show & Tell where you can meet and ask questions of the team, we issue a monthly roadmapof our scheduled work and our product backlogs are available online for scrutiny at all times.

All of these set pieces, as well as other informal forums make it simple and quick to find out who’s doing what and when. Our openness has been complimented by colleagues at Bath and beyond. There’s always more that could be done, but I am happy that we set a good example for others to follow.

Always aiming for more

We have turned Digital from a unit that simply plugs-and-plays with other people’s software into a team that creates products and runs services. This puts the University in the rare position where it can buy-in or manufacture what it needs based on the objectives and resources to hand.

This is not a luxury, this is a hard-earned and competitive advantage that has involved reskilling and retooling the team, including moving away from a Java based infrastructure to writing applications in Ruby on Rails, establishing pair writing in content and designing mobile-first prototypes in browser. With that power comes great responsibility which we have embraced by upgrading our user support services in parallel.

Judgement by results

The sum of all our new products, services, processes and culture has been growth across all our key performance indicators.

Visits and views are up in the UK and worldwide overseas locations, especially in target overseas markets. Our bounce rates are down and our page level engagements are up. We have launched new sections for Research and first year students and have provided for users’ preference for mobile devices. Furthermore, our volume of incident tickets and downtime have both been slashed.

These results are regularly reported to management and available to staff and students to scrutinise. We have begun to help other teams around the University to supplement their performance reports with digital metrics, which is the beginning of something very important for monitoring return-on-investment and establishing what ‘world class’ really looks like.

Going is good

In an era of pronounced competition across the sector, the hard facts are that Digital’s leadership and delivery has resulted in more traffic and deeper engagement across the University’s activities on- and offline.

It may all sound like a lot of stern, disciplined work but it’s actually been a lot of fun. The Digital team is full of generous, humble and creative people. We all get on well and we bring out the best in one another. There have been laughs every step of the way.

So the going is good. And I will be watching on from my new post in theScottish Government with pride.

Many of the most important developments I have brought in are cultural and procedural. The people who have the technical expertise to deliver on the potential remain in post. All they need now is the reciprocal trust and material support of their colleagues in order to capitalise on the gains Bath has made in the last 36 months. Do so and the collective rewards for the University will be worth it.

So keep being ambitious.

Cue the music…

What’s going on at the Government Digital Service?

Oooft! What’s going on over at Aviation House? Only the end of an era, that’s all.

First Mike left and then the triple-whammy of Ben, Russell and Tom all saying sayonara at the same time. It’s all been a bit of a shock, even for wise-heads who might claim to have seen portents of its coming to be.

Mike, Ben, Russell and Tom – I’ll say again – you guys are awesome! You’re contribution in building digital infrastructure that this country can be proud of will ring out for a long, long time.

Scotland the Brave

It’s a brave thing that Scotland is about to do.

Are you for or against Scottish independence? I’ve been hauding ma wheesht for a long time on the matter. Thinking it through. But with a week to go until the big decider, I wanted to take part.

View this post on Instagram

Wear it with pride @rossferg :-)

A post shared by Dan Dineen (@dandineen) on Aug 20, 2014 at 4:51am PDT

I don’t get a vote in the #indyref because I live outside of Scotland. A fact that is very hard for a tartan-totting, loch-loving, bru-swilling born-n-bred Scotsman like me to bear. Instead I need to find other means of participation. People who know me know that I believe it’s incredibly important for citizens to engage in democratic processes like the opportunity presented to the people of Scotland on September 18th 2014.

On the night of the first televised debate I was in Scotland, back in my home town. Instead of sitting in the house glued to the Salmond and Darling Show, I was out the back of my pal’s house playing cricket. Cricket?! I never play cricket but here I am in Scotland, in the town where William Wallace killed his first Englishman, with two other fiercely-proud Scots, one of whom is a big ginger sporting a tattoo of the Lion Rampant on his leg, and we’re dabbling in a spot of leather on willow. My point being that these Scottish lads are fundamentally the same in outlook, values and spirit as my mates 500 miles to the south in Billericay.

For me, the differences aren’t so apparent between Scotland, England, Wales and Northern Ireland as to justify a yes vote. No one is oppressing us. We are a recognised nation. People beyond our shores already recognise and love Scottish. People get that we are different to the rest of the UK nations, yet we can still have all the benefits of association when we want it. Devolution has barely gotten started. We can have the best of all worlds, why limit ourselves on the basis of a plan that amounts to little more than a longwinded party manifesto. That’s my view. I’d be a no.

Whatever the result on the 18th, the Scottish people are going to have to go bravely into the future as one. What’s clear is that we have to reconcile ourselves quickly with the result and take full advantage of this renewed focus on being a nation again, a forward-thinking nation of people who are good to one another and good with other people beyond our already well-kent border – whether we’re an independent state or not.

I’d think it was the wrong decision to go independent, but if that’s the choice I’ll get fully behind it and help to make it work. Hell, I’ve seen enough of British politics to know it needs a big constitutional change to reinvigorate it. Independence isn’t what I had in mind but I’ll run with it, if my people make it clear that they want it.

But it has to be a clear result. The worst that could happen is that the people don’t turn out. The Scots have shown ourselves not to be the hottest at voting in recent opportunities, especially Scottish parliamentary elections. When I was up the road recently too many people said they might not bother voting. As a proud and passionate Scotsman that was hard to hear and I implored them tae think again. That’s why the news today that a historic 97% of the adult population registered to vote in the referendum is so amazing.

And that’s my say. Not to push an aye or a naw. But to push for Scotland the Brave. For Scotland to turnout in droves and make themselves heard whatever the decision. The legacy of this event depends on it.

Make sure you get involved. Good luck with it all folks.

The pleasing difficulty of judging a hack day

Bath:Hacked is asking the brightest and most creative people in our city to spend two days thinking, playing and hacking an untapped seam of BANES data.

It was with huge excitement that I headed along to Coworking Bath on Sunday morning for the judging of the first Bath Hacked event.

I arrived around 11AM, by which time the teams had been working for over 24 hours on their hacks. I spent 5 minutes or so with each of the teams in turn, looking at where they’d got to and getting a feel for where they were heading in the rest of the time they had.

There were no set judging criteria as such but I constructed a set of questions that I asked of each team I met to get a feel for:

• The clarity of user need(s) being addressed
• The importance being placed on the quality of user experience created
• The application of locally-sourced data, especially that recently released by B&NES for the event
• Tactics employed to clean, munge and splice data to make the data meaningful.

Around 3PM, the teams gathered together and presented to one another, the judges and a big group of curious onlookers for 4 minutes. Then it was over to me, Doug Laughlen and Valerie West to try to decide which team should win in each of 4 categories:

• Grand Prize (£1k) – awarded to the best overall project, judged most imaginative, well conceived and likely to benefit the community, local business and/or the environment
• Community Impact (£250) – awarded to the project most likely to resonate with the wider community
• Best use of data (£250) – we’re looking for useful, clever or just plain surprising ways to use local data
• Best completed project (£250) – shipping certainly isn’t mandatory, but there’s glory for those who manage it!

Delivering a digital strategy for the University of Bath

First published on University of Bath Digital Marketing & Communications blog

In recent posts, we’ve alluded to there being a University of Bath digital strategy. It’s the product of analysis and interviews conducted over the last 3 months, and we have begun taking that strategy around campus to introduce our colleagues to its contents and to get their feedback and support.

Our strategic goal
The University’s goal is to have a world-class digital domain developed around the needs of its users. This digital goal is framed by the actions set out in the University of Bath’s strategy for 2013 – 2016.

Users of our digital domain include students, academics, corporate staff, businesses and the public. While the majority of our digital users are here on campus, we receive high volumes of traffic from elsewhere in the UK and increasingly overseas. Our website serves in part as a marketing channel but our users are mostly task-driven and view our digital domain as a collection of services they use to get things done.

We want the people who use our site and associated digital channels to regard them as informative, trustworthy and useful. We believe that the manner in which we meet our users’ needs sets us apart from our peers and when we perform well it has a positive impact on the reputation and visibility of our research and teaching.

Trialling delivery principles for the University of Bath Digital team

First published on the University of Bath Digital Marketing & Communications blog

The University of Bath has an in-house digital team. There are currently 11 of us and we are a mixed-discipline team of designers, developers and editors.

In recent weeks, the Digital team has been taking a hard look at what we do and how we do it in the interests of being more effective. We’ve run retrospectives of our work, been in conversation with folks we do work with and for around campus, and we’ve studied the way other digital teams work.

Our team provides digital products and services related to study and research, which are used by the University’s students, staff and partners as well as by the general public. When we looked at other teams in the digital industry (who provide products and services), we saw some had written down a set of principles that they worked to and this practice resonated with us.

From what we understand, delivery (or design) principles have many benefits. They draw a team together and provide a common thread throughout all its work. They help end-users understand the efforts that have gone into content, designs and features, and how the team might develop things in the future. And, they serve to manage the expectations of delivery partners and senior management about how the team is organised and what motivates it to work to the best of its abilities.

As we have reflected on our past work and the sort of team we want to be, we have zeroed in on a set of beta (or trial) delivery principles of our own. Here’s what we are starting with:

1. Put users’ needs first
The products and services we deliver should be driven by the needs of our users, not what suits us as providers. This means investing the time and effort to regularly engage with users and the contexts in which they interact with what we produce.

2. Make decisions based on data
Simply stating a user’s needs is insufficient, we must have evidence to make it compelling. We have been hired because we have good opinions and instincts based on professional experience. But we need to counsel these with sound qualitative and quantitative data, and use that data to make objective decisions about what to deliver and when.

3. Release iteratively and often
We will not store up ‘big bang’ releases because that is frustrating for the users and risky for the organisation. We will start small with the minimum viable product, we will test it and we will release it as soon as possible on a timescale of days and weeks, rather than months or years. We will repeat the process many times over, adding to our products and services based on feedback, tests and changes to technology.

4. Keep it simple and consistent
We run a big site with many supporting many channels, which draw in a diverse set of users who have an expectation of quality associated with the University of Bath domain. We will do the hard work not to over-think or over-complicate things. Whether a user is new or experienced, task-driven or browsing, they will able to get started quickly, flow through the process with ease and trust the integrity of the results.

5. Do the hard work behind the code
The success of a great digital product or service doesn’t rest entirely on what  appears on screen. To deliver accurate, pleasing and sustainable products and services means investing in simple instructions, efficient workflows,  accurate monitoring and great support. Often this can all be provided by the Digital team directly but we also expect to work hard with our partners on getting this right.

6. Work in the open
We will share what we are doing as often and as freely as possible because we believe that scrutiny makes us a more effective team and our products and services better. This extends from our product backlog through to the data generated by our output. We will ensure that we provide updates, explain our actions and demonstrate where and how we have taken on board feedback.

Now that these principles have been written down and shared, the hard work of putting them into action begins. We will apply these principles regardless of the scope or scale of delivery. We will apply these principles to our delivery regardless of whether we are a designer, developer or editor. We will apply the delivery principles regardless of whether we are working completely within Digital or with people outside our immediate team. And you can hold us to account when something we produce seems to be falling short of these principles.

There is no orthodoxy or set of rules to follow when choosing principles. Delivery principles are context specific, based on who’s in the team, what the team is having to do and over what period of time. Our principles are based on best of breed examples in the wider digital industry but have been adapted for the specific circumstances of this University’s Digital team.

As we develop as a team and work our way through our backlog and goals, we expect these principles to evolve. They will change based on our own direct experiences and on the feedback we receive from our users and co-producers. As and when substantial changes take place, we’ll keep you updated. Please also check back for posts capturing case studies of these principles being applied to real products and services that you can click on and use.

We’ll always keep the latest version of these principles published on our wiki.