Creating Software - A Sisyphean Task?

Product Management is not about what you build but what you inherit

2023-10-21T12:25:00.002+01:00

Software Product management isn’t about creating products...

For any product folks reading this who have just spat out their coffee, allow me to explain. How many product managers do you know that have actually led the creation of a net new, greenfield product? I don't know many. In the modern investor funded software startup landscape it is more often founders that lead products in their early stages. Typically a devoted product specialist is only introduced after a funding event or period of growth. Therefore I'd argue that it's a much more common scenario that product people inherit products rather than creating them.

Why is this important? This pattern is critical to understand because for any product folk working in startups. The first 6 month to 1 year product strategy is going to be dictated by decisions made before you rocked up. And because you never know what you're going to get.

The shapes of inheritance

It's easy to oversimplify any challenges in the state of products that you inherit under the banner of 'tech debt'. But product debt can come in many forms, and I think a more nuanced view may help us to understand these situations better. So to that end - here are a few shapes I've seen that you might find familiar :

Poor PMF

This is when a PM takes on a product that solves a problem for a few customers but isn't gaining wider market traction. The small customer base who rely on the existing features makes it hard to pivot, but there is little growth opportunity with the product as it is. Competitors more aligned to the market are accelerating into the distance.

This is a tough situation. Not every PM gets the option to jump on board with the next unicorn startup and sometimes taking a role with a revenue making but low growth product is the best option available.

What this looks like to the PM

Sales are asking for competitive capabilities which aren't possible to add to the product as it stands
Product discovery uncovers problems and opportunities you are not well placed to solve
Too much time is spent poring over the product trying to find a value for proposition to take it to new customers

A sales led swiss army knife

I've encountered this situation when a company doesn't have a strong product and has had to resort to 'closing code' to win every deal. At best this results in a host of little used and incompatible features, at worst you end up up with a cluster of standalone products connected only by style and brand. Sunsetting is difficult as each feature is contracted in to a major customer. Trying to build out common features is impossible as no two customers use the products in the same way and every new sale involves custom work.

What this looks like to the PM

Sales have an eye watering list of options to sell with little understanding of which to present to which customer segment
The customers are demanding a more coherent product and reporting experience but behind the scenes they're using a mess of disconnected data and features
No-one knows if certain features even work together and major issues are uncovered with alarming regularity as novel feature combinations are sold.
Different approaches are used to solve the same problem across the portfolio so customer configuration is a confusing experience and your service teams are the only ones that really know how set things up

Too narrow a domain mapping

This happens when there is a genuine and valuable problem but the solution created doesn't map to it well as it's far too aligned to one specific case. This is a challenge I've seen with products where a single main customer or stakeholder has led the product decisions in the early stages (agencies and consultancies trying to leverage their bespoke tools for a wider market also struggle with this). The features and underlying data structures will align to one specific instance of the problem domain, often a specific integration one customer is using, but lack the flexibility and extensibility needed to grow the product to address the wider market opportunity.

What this looks like to the PM

Nothing you want to add quite fits how the existing product works
Adding what appear to be simple features is prohibitively expensive
Trying to extend the product to new use cases would require duplicating most of the database

The technology won't support the rate of growth.

Simply put - this is where at the rate the product use is growing, a part of the tech stack will cease to function effectively soon enough to present a tangible risk. While this could be due to poor technical choices, it can also be a sign of sensibly avoiding over-engineering at a stage it wasn't needed. The need for scale is, after all, a sign of a market fit some products never achieve. This article from Klaviyo is a great example of a company having a solution that allowed them to scale to a point, but rearchitecture was needed to grow further.

The obvious risks this situation presents to the incoming PM are that the time to address the problem is greater than the engineering runway available, and solving the problem involves diverting effort away from anticipated new features. It's therefore vital to have a handle on the impact timelines of the problem to ensure you factor in the necessary work before running out of road.

What this looks like to the PM

There's a huge technical backlog project that has been repeatedly deprioritised to focus on new features
Performance of background and data processes has started impacting user experience
There's tension between CTO and CEO about devoting time to the problem
More and more time is being devoted to engineers ‘plugging the gaps’ and freeing up time to work on a new approach is getting harder

You can't just stop

Unless you start your own company, as a product professional you're probably going to hit one of these scenarios at some point as you step into a new role and take over the product reins.

One thing to flag up is that - in the face of some of these challenges you will probably get a strong push from engineers to rewrite pretty much everything. This is an understandable response - the allure of a clean code base with shiny new technology has a strong pull. From a product and ROI perspective this is an extreme option and hard to justify.

You will also get a strong push from the CEO and commercial teams to deliver new features. The situations I've outlined here will almost certainly result in a slowing of team velocity over time and one of the expectations of you coming in may be to 'speed things up'.

In early stage companies maintaining momentum is vital both in terms of growing the product but also giving the wider team confidence in delivery. Nothing puts talented sales and marking folks off more than a product that isn’t changing - and full scale rewrites rarely deliver the value promised in the time expected.

Taking the right Approach

So how do we strike the balance? To be honest I have as many questions as answers on this, I've certainly not found any silver bullets. Here are some approaches I've found useful.

Present a strategic position

As Richard Rumelt outlines in 'Good Strategy, Bad Strategy' a strategy requires a solid understanding of current position. The top priority for any incoming PM is therefore to find out as quickly as possible what they have inherited and present the state of play clearly to the CEO and senior team. Only then you can go on and present an achievable product strategy.

Use sponsor initiatives to drive change.

Instead of flat rewrites an approach I have used multiple times is to tackle problem areas through product initiatives. If we need to rework an area of the product let's look at what the next valuable iteration of that area could be and build to that. In this way we at least maintain new value through the roadmap while tackling our debts. The risk here is a perception that these features are taking longer than they should, so this needs to be supported by strong communication on the underlying benefits of the rework additional to the immediate feature being delivered.

Start investing in the future.

A lot of early stage product decisions are entirely tactical as founders try to find a market fit. Joining as the first product hire, particularly off the back of an investment round, is the right time to start investing in future growth and it's your responsibility to carve out time in the roadmap for that. Starting research initiatives to understand and de-risk the biggest challenges build vital company momentum towards tackling them.

Don't be scared to shake up the roadmap.

If you are truly stepping into an empowered product leadership position then it's your responsibility to drive change where it is needed, even if this isn't the direction that was expected when you joined. Dropping unnecessary developments is as important a step here as creating new ones. I have terminated a number of engineering initiatives in the early stages of a role simply because the proposed benefits didn't justify the investment. Any changes will obviously need to be backed by reasoning - but highlighting the absence of supporting evidence behind a development is enough for you to reprioritise.

Inheritor Beware

Inheriting responsibility for a product is a risky time. No matter how much you look into a company in advance you never know the full picture until you get through the door - in every role I've stepped into there have been surprises. You may assume I'm writing this because of my current role. This isn't the case - while like every company we have challenges, but it's actually because I'm in a very positive situation right now that I feel I can openly write a post like this.

This hasn't always been the case. Sometimes it's gone too far. Sometimes the lack of addressing the big problems takes a company to a point where they run out of capacity to fix them without basically rebuilding from scratch. If things have been allowed to reach this point then a realistic assessment of the situation is not what the CEO wants to hear and you've probably been brought in to magically make development go faster. If that's the case then at least you have fair warning that the expectations of the role are unachievable. As influential tech recruiter James Jordan wrote in this great post - there are many reasons for short tenure in product roles and a mismatch of expectation on what's achievable is a common one.

Caveat emptor is the latin for 'buyer beware' - perhaps a more appropriate term for product managers is caveat heres or 'let the inheritor beware'.

Photo from: https://picryl.com/

Are Product Teams Harder to Lead?

2023-04-03T21:13:00.002+01:00

Are product teams harder to lead than other R&D teams? This is a question that I've been mulling over recently. I've been leading teams and departments of various disciplines for many years and my experiences in product have been some of the most rewarding but have also at times been the most difficult. As I'm in a lone-contributor role right now it seems an opportune time to reflect, so in this post I'll look at what it is about managing product roles that makes it feel like so much more of a balancing act than leading other disciplines.

Product roles are mortar roles

Someone once said to me that there are two types of job in tech companies, brick roles and mortar roles and that product was a mortar role.

Brick roles are well defined value delivery roles that are pretty consistent from one company to the next - development and technical support are good examples
Mortar roles are more connective, working between the 'bricks' adding value through facilitation and negotiating decisions. These tend to have far more variable expectations according to the structure of the company

Product roles do vary hugely between companies. A product owner in one company may have full responsibility over their product where in another company they may be there to manage the backlog of priorities given by a senior exec or PM. Some product roles regularly speak to customers whereas others are limited to working with internal stakeholders who tell them what the customers need.

Product roles are highly distributed across the organisation

In teams with a common workload such as developers or technical support the team will usually focus together on a narrow set of work items. A product team is different in that it behaves more like a number of separate teams all made up of one person. This is because each individual is aligned to separate agile teams, products or value streams. The result is that often there is as much work in progress across a product team as there are members of the team, if not more.

Product roles are highly autonomous

Working across such a distributed group all with discrete workloads means that the product team are never going to work as a close-knit unit. Product owners and managers therefore have to be independent decision making roles. There is a truck load of autonomy inherent in the roles and each individual will want to adapt their approach to fit their unique context. This makes any attempt to manage by standardising processes across a product team an exercise that's unlikely to provide any benefit and could be unwelcome. Leading product is a fine balance of finding structures that give a consistent view to colleagues and customers while not inhibiting individuals in how they approach their work.

Product roles aren’t in control

Yes we can set priorities but product folk are abstracted from being able to deliver value into their products directly. The need to deliver through influence is key to success in the role but it does make it harder to assess how someone is doing. Sometimes limitations in technology or simple technical capability in teams can hinder the most capable product owner from getting value delivered.

Lots of product work is based on the effectiveness of the interactions they have with others and you can’t easily assess that influence in the same way you can the quality of a piece of code or the rigour of a testing report. For this reason understanding how well product people are performing often falls to speaking to their peers and internal customers. This isn’t helped by the fact that being effective in a product position means saying no to these very same people on a regular basis.

Product people are harder to find

The combination of technical understanding, commercial insight and communication makes product roles hard ones to fill. In fact after a lengthy study Adi Agashe and Parth Detroja in their book ‘Product Management's Sacred Seven’ found that there were seven core skill areas to being a successful product manager - Product Design, Economics, Psychology, User Experience, Data Science, Law & Policy and Marketing & Growth. Few roles can boast such a broad range of skills as the foundations to success. Good product people are therefore very hard to find.

So why do it?

While it's easy to dwell on the difficulties product leaders face, what it's worth remembering is that it is also great fun. Those characteristics which can make product teams hard to lead also reward in equal measure.

Product people are motivated - I've not yet met a product owner or manager who didn't have a genuine passion for what they do. Drumming up enthusiasm isn't a problem in product teams.
You can be a genuine servant leader - Good product people don’t require a lot of hands on management which means that adopting a servant leadership style is a natural fit. As I wrote about in ‘the Sacrifices of the Servant Leader’ being a good leader is not about telling people what to do. Instead it’s about supporting people to get the best out of them and allow them to shine.
Product people are creative - Good product people are a pleasure to manage as they bring ideas and spark off each other and the teams they work with. Getting to engage with talented, smart and creative people and see them driving innovation is one of the true pleasures of software development

So on reflection is leading product teams harder? I don't think so, however I do believe that it is unique. Product teams require leadership rather than management to ensure that you get the best out of a group of talented, creative and autonomous professionals. If you get the right people and support them well then a product team can create a real buzz around product in a company, and it’s a joy to watch this happen.

Photo by Michał Parzuchowski on Unsplash

Is UX the new waterfall?

2023-02-27T22:10:00.004+00:00

‘It’s a real problem’ my host admitted as we walked down to the entrance lobby. I was in the main office of a major social media company in London a few years ago after completing some user research with their team. The topic we were discussing was how to embed UX discovery and design processes into agile teams without losing the benefits of agility. He didn't have a good answer. Instead he acknowledged that it was a big challenge that even the tech giants struggle with.

Where we came from

Some reading this may not have experienced working on a good old fashioned waterfall development project. They will have missed the protracted business analysis process and the joy of repeated document reviews, version edits and sign off that preceded any development.

When agile came along it provided a new found freedom for software product teams. A shift to conversations over extensive documentation brought developers closer to their users. Small, frequent releases allowed teams to focus on current problems with relevant solutions.

At around the same time that software product teams were discovering agility, a shift was also taking place in the world of websites - an increased focus on User Experience. The growth of e-commerce meant that websites had become major revenue drivers in their own right. A refined user experience became vital to harnessing the opportunities of commercial websites and marketplaces. Even the smallest uncertainties in the user journey could impact key metrics like basket completion.
As this Nielsen Norman summary of the history of UX explains - the "Web Revolution" through the '90s and '00s was a major driver in UX due to the changing role of software in the buyer journey.

on the web, the sequence is user-experience first, payment second. Making UX the gatekeeper of the money vastly increased executives’ motivation to invest in their UX teams

Two worlds collide

While often discussed collectively, looking back it's clear that the rise in popularity of agile and UX were driven by quite different motivations. At the risk of oversimplifying -

Agile adoption flourished in situations when the software was the product
UX methods were popularised in situations where the software sold the product

With the rise in popularity of SaaS what we have seen is an interesting coming together of these two forces under the banner of 'Product led growth'. Now the software both is the product and sells the product. B2B enterprise tools historically sacrificed polished design for an extensive feature set. Users of modern B2B SaaS products are still expecting rich and powerful functionality, but a consumer grade web/app experience is needed to drive adoption and license expansion.

In this shift lies the crux of a challenge to modern agility. SaaS product development involves the bringing together of two worlds that seem to be in opposition

Agile product teams who want to solve the highest priorities of their users incrementally on a sprint-by-sprint basis
UX research and UI design teams who want to follow a user-centred research process through multiple stages of prototype through to a final design

I've seen two responses to this tension.

Reverting to waterfall

The first approach I've seen is where user research and design are tackled as a pre-development project. A common driver for this can be the use of UX agencies through a reluctance or inability to hire permanent expertise. The shape isn't limited to external teams though, and in house design teams can also tend towards this shape if they adopt agency working patterns to serve internal customers.

I've seen this approach throw up a number of challenges

Data complexities take deep understanding. Anyone that's worked with a complex digital product will know how important it is to understand the data structures that support it. Design projects aimed at rethinking the user experience can fail on implementation if the interactions don't allow for underlying complexity.
User needs emerge organically. While it's certainly possible to lay out an initial design principal, a lot of learning comes from seeing users interact with a product over time. Observing how the software is used helps to drive small but impactful improvements.
It's hard to convey context. Even with an extensive Figma design and handover documentation a lot of context is lost when a design is 'handed over'. This makes it very hard for developers to refine and adjust if any element of the design isn't practical to implement.
Missing the art of the possible. Ironically when design and engineering are separated the result can be a lack of real ground-breaking innovation. External UX redesign projects I've seen have tended to limit their focus on reworking navigation and onboarding journeys. This should come as no surprise given that these are the foundations to success in the ecommerce arena. Genuine software product innovation needs input from those who understand the whole solution and what may be technically possible.

This all seems hauntingly familiar. By adopting modern design methods as a stage in a process we've undermined any of the benefits that agility was providing. Development teams aren't engaged with solving problems and are instead reduced to feature delivery teams. User stories go from being placeholders for a valuable conversation to little more than a novel structure for paragraph headers in a specification document.

A better way

There is an alternative to splicing UX design and agile together into 'waterfall mkII'. It involves developers, testers, product and UX designers working together as part of a cross-functional team. Discovery includes not only UX activities like user interviews and wireframing but also technical discovery such as research spikes and functional prototyping. While they don't need to participate in every process, each member gets visibility and input at every stage. While discovery and solutions ideation is still done ahead of development, the whole team are engaged with the end-to-end process.

A popular name for this approach is ‘dual track agile’. While not a term I necessarily promote, it kind of makes a lot of sense as the name conveys that there are still multiple processes going on (though I think there are more than two). It is unrealistic to expect to discover, prototype, refine and deliver complete solutions under the banner of a single user story in a sprint. Even multi-functional teams still need to split the work into separate 'tracks' to allow time and find the right cadence for each activity.

Discussing the practicalities of adopting such an approach is a topic for another post. I will say this is a difficult balance to achieve but when working well it is possible to obtain the benefits of both agility and great design:

Discovery at every stage making everyone accountable for ensuring the solutions provide the outcomes being targeted
Visibility for developers into discovery activities even if getting them fully involved in customer proves impractical
Technical expertise focussing on analytics helping to ensure user behaviour analytics is well supported in the product
An engineering team involved in solution ideation to provide informed input on viability before time and effort is put into impractical designs
Availability of designers through the process - for me this is essential to explain their thinking and provide input if the original idea proves technically impractical

Don't underestimate the problem

Writing this post has given me a clearer appreciation of why UX design in agile is such a challenge. When considering two modern schools of thought that both have a focus on user understanding at heart it's easy to assume they should be compatible. What we need to appreciate is the popularity of each approach has had different motivations. We can't assume we can combine expertise and methods that have quite different origins and retain all of the benefits. Nurturing a healthy whole-team process of discovery, innovation and delivery is a challenge, but the rewards are worthwhile and the journey to get there is for me, in my current role at least,one that I relish

References

This Nielsen Norman article on the history of UX provides a fascinating look into motivators of the growth of UX methods
This by Jeff Patton is my favourite article on Dual Track Agile

Main photo by Jonatan Pie on Unsplash

Hiring Product Roles and Looking for Unicorns

2023-01-20T09:36:00.006+00:00

I have recently found myself with an interesting insight into the software product talent market, both from the position of an employer looking for talent and in my own search for a next opportunity. I've interviewed a lot of product candidates and also read a wealth of job adverts. What is apparent to me from engaging with this process from both sides is that, in the UK at least, there is a huge disparity between the capabilities and experience expected in product hires by the recruiting companies and the experience available in the market.

A difficult role to hire for

Finding product people is hard. I've been hiring product roles on and off for 7 years now and it hasn't got any easier in that time to find capable people.

The reason for this I believe is that product roles have a unique set of characteristics that make them particularly hard both to hire for and for people to deliver

They are hugely responsible - product roles are key decision makers in technology development and carry a huge weight of responsibility on them to steer team and product direction and prioritise the right things.
Product role autonomy varies massively between companies - one organization's idea of a product owner will be little more than a user story administrator processing features dictated to them by the leadership team. Another's will be a mini CEO with complete autonomy over direction of a product as long as strategic outcomes are achieved.
Applicable skills vary hugely between contexts - The relevant approaches for success in a B2C product context will be very different from an enterprise B2B product company. Methods for discovery, measurement and validation differ widely depending on the scale and nature of the customer relationship.
They require a wide variety of both soft and hard skills - from technical and data familiarity through customer communications, stakeholder management and process management to marketing and commercial acumen, few roles can boast quite such a range of capabilities needed to do them effectively than product owners and managers.

These novel traits make the process of moving individuals between product roles in different companies a risky and error prone business.

We want certainty of success

At the same time, the increased focus in recent years on senior product roles across organisations leads to high demands in hiring companies. Many operate with the expectation that individuals exist not only with the extensive list of skills referenced above, but also with a history of working in multiple successful startups.

Here are a few examples of product job ads I've seen recently

"Demonstrable ability to build and scale a Product organisation in a high-growth startup or scaleup setting."
"... previous experience building a world-class product function from scratch utilizing their network and other external resources"
"You have worked at the highest product level at a large successful startup, where you have been successful and now want to translate somewhere new"

All of these and similar phrases translate to the same thing

"We want to guarantee success by finding someone who has worked in a unicorn startup before and can apply the same magic here"

But is this realistic? I can understand the desire for certainty here, but there are good reasons why finding product people who have previously taken a new product through high growth is a blinkered strategy.

Great market fit is a springboard for success
If the core product concept is strong enough from the founders then success will have momentum behind it for anyone stepping in. Putting equally capable individuals into companies with stronger or weaker product offerings will yield very different outcomes and just because someone has been successful with a great product concept doesn't guarantee that they'll be able to do the same with yours.
Luck also plays a huge part
With 60% of new businesses failing within their first three years (https://www.beauhurst.com/blog/startup-fail-scale-exit/) yet only 8% of start-up failures attributed to poor product (https://www.cbinsights.com/research/report/startup-failure-reasons-top/) there are a lot of potentially good product people out there who haven't been lucky enough to enjoy scaleup success through no fault of their own. I've spoken to some great product managers whose companies failed to grow for reasons they had no influence over - they were just unlucky.
Success opens up new opportunities
Those that have successfully worked in a start-up through to exit may not want or need to again - the product people that I know that have seen products through high growth to successful IPO or acquisition found themselves in a very different position as a result, both in terms of personal finances and reputation. Consulting, training, non-exec positions, writing a book or simply not working can suddenly become available options that may be more attractive than starting back on the first rung as product manager in another company.

The net result

I’ve been in the software industry for a long time and haven’t met that many people at any level with the range of skills expected in most senior product adverts, let alone those working in Product roles. Add further constraints of having driven a successful start-up to exit, and still wanting to stay in a full time product role, and you really are hunting for unicorns.

It's not necessarily a bad strategy to 'ask for the moon' and see what you get, but I believe there are risks. At best I fear that this kind of approach excludes capable candidates - such as those who have worked in more mature businesses or the majority of startups that didn't hit the big time. At worst it drives a talent market that favours those who pursue short term quantifiable wins to grow their personal profile over addressing the important but unglamorous needs that are vital to build long term company success.

Image: Wikimedia commons public domain

Building products in services companies

2022-11-13T15:56:00.005+00:00

I’ve worked in a couple of organisations that were coming from a background of a services based delivery model and trying to move to being product companies. The motivation for this kind of move is clear when revenue multiple valuations are so much higher in the product space. What I’ve seen from these experiences is that the route to success is far more challenging than people realise. Here I’ll dig into some of the biggest common challenges I’ve encountered that can hold these companies back.

With Products there’s no backup plan

Building products is hard. Don’t get me wrong I have huge respect for anyone that work closely with customers in a professional services context and keep them happy. Its just that building products is a much more proactive endeavour than delivering consultancy or bespoke projects which have a higher level of reactivity. It takes a lot of discovery effort and discipline to create a product that meets the needs of multiple customers in a consistent way with a common feature set.

When creating technology in support of a services-led offer you are operating with more of a safety net of filling the gaps in product functionality with people. This could be by taking on the project administration yourself or running some reports or communications outside the standard product workflow. When creating products a lot more time and effort needs to go into providing a coherent and complete experience with each increment - as throwing people at the problem is not an option.

A different basis of success

There’s an interesting dichotomy in some companies between what they think is the basis of their success and why the customers use them. Many services companies are founded based on a deep domain expertise - usually in one or more founders. These will inevitably feed some standard frameworks or company collateral that adds value through credibility. It will ultimately fall to the project teams providing that service to ensure a valuable delivery to the customer through custom content creation and design alongside high-touch delivery.

While it may not be political to say it - there’s probably a much higher reliance simply on the quality and flexibility of the service and the talents of those in sales building deep customer relationships than any 'secret sauce' baked into their approach or technology. The market knowledge of individuals negotiating the sales and delivering the service, their competence and their responsiveness to customer needs will have been a massive driver of success historically in a successful consultancy or agency.

Overestimation of IP

A natural consequence of the above is that service companies tend to place a much higher valuation on the IP within the business than is realistic. This presents a challenge when these companies look to capture their approach in scalable products. Once you remove the high value-add that the service provides, there's likely to be a much thinner basis of value to encapsulate into a product experience than they may want to admit to themselves. There's a high chance that the competitive landscape suddenly looks very different when viewing things through a product lens, with more ‘out of the box’ providers suddenly looking a lot further ahead on the journey a company plans to go on than they are given the competitor's higher relative investment into technology, user experience and product-led growth.

Another area where IP can be over-valued is in having large quantities of data collected. Unless data is explicitly collected with the relevant categorisations and ‘levers’ to connect it to meaningful business decisions then it will be difficult to monetise. To grow a valuable corpus of data requires forethought and planning, it's unlikely that a services company will create themselves a data goldmine unintentionally.

A company I worked with a few years ago had the good sense not to assume there was value in their data and engaged an expert data scientist to analyse the huge amounts of management data they had gathered - the results were predictably disappointing and they found no monetisable value at all. If you want value in your data you have to build it in from the start.

Project based technology

Until the explicit decision to create tech products is made, most software in services-led organisations will be spawned as part of a customer project - and then leveraged and built on to deliver to other customers.

The result is technology that has been created ‘incrementally’ rather than ‘intentionally’ - and without the architectural rigour that comes with investing in a product that is designed to serve multiple customers with common features from day one. By the time the needs of the fifth or sixth customer use case is supported a rapidly developed tool can become a heavy burden for the engineering team to carry. Even when the intention is there to build more cross-cutting products the temptation to sell these too early before the product is ready can result in making massive compromises as extensibility and scalability are dispensed with to meet a customer project deadline.

Not wanting to say no

A vital element of a product relationship is an ability to say no to customer requests if they don't fit with the direction you want the product to go in. This is a much easier discussion with the right basis of the relationship from the outset. It's a bitter pill for a customer to swallow when they hear no for the first time after years of getting their every request serviced.

The same applies internally. Sales teams whose Ideal Customer Profile is ‘anyone with money’ and who expect to get new features added from one customer project to the next to hit their revenue targets may not respond too well to shifting to a ‘Now, Next, Later’ roadmap.

Creating products should implicitly be an agile endeavour to focus on and deliver the highest value incrementally - however there is a level of proactivity involved in exploring the needs of many customers and ensuring good solutions to common problems or valuable opportunities. A culture more used to reacting to customer requests and getting them delivered may find this hard to grasp.

Too broad a focus

Not saying no doesn’t just apply to customer requests - there’s also a need to say no to opportunities or even market sectors if the product portfolio isn’t best set up to serve them. Good product companies will target one market segments, drive discovery and development towards serving their needs and grow the range of segments supported over time through intentional development of their product portfolio.

When a company is chasing revenue rather than growing out a product vision the result will be a weak set of offerings across a wide range of segments, typically prompted by targeting one or two opportunities in those areas and spinning up tools to serve them that rely heavily on the previously mentioned safety net of being able to fill the gaps in capability with people.

A big challenge

The challenge of shifting a technology-backed but service-led company into a product one are significant and one that as a product person I suggest approaching with caution. It’s no coincidence that my writing has taken a pause over the last year while I’ve been taking on such a challenge - I don't find a lot of inspiration in the political conflicts that are involved. Even when I've had similar roles in the past that I enjoyed more - they still involved significant battles with account teams over responsibility and prioritisation decisions as we strived to create core technology platforms under the banner of major customer projects.

If you relish the challenge of shifting a culture and overcoming resistance to taking a different approach then this kind of role may be for you. For me personally the political challenges and conflict negotiation involved are simply not problems that I relish solving.

References

For a great summary of product and professional services companies and the slippery half-way point that sales driven enterprise software companies can fall into see Rich Mironov's article here https://www.mironov.com/sales-led/
This great article by Janna Bastow highlights the risk of service vs product delivery https://www.prodpad.com/blog/avoiding-the-agency-trap/
And the’bad revenue’ section of this newsletter from Jason Knight is also well worth a read https://oneknightinproduct.substack.com/p/mental-health-for-pms-the-importance-of-messaging-web3-and-thinking-about-revenue-debt-1409887

A Simple Rule for Product Decision Making

2021-11-08T21:11:00.022+00:00

A good alternative job title for most product roles would be 'professional decision maker'. Whether deciding priorities, experiments or potential features, pretty much every action a product manager takes is to decide between conflicting options. I saw a great talk by Geoff Watts a few years ago on decisions being the essence of Product Management - Geoff explained that, while decisions may work out well or badly, at least by making a decision you progress and learn. Inaction through fear of making the wrong decision, on the other hand, will inevitably lead to eventual failure, by which time it may be too late to recover.

The hardest decisions for many product people revolve around whether to take the quicker route to short term value or tackle larger scale improvements associated with longer term strategy. I'd never suggest there's an infallible rule here, but there is a guiding principle that I try to adopt which has served me well both in product decision making, and also my own personal career choices.

Don't pass up an opportunity to progress to where you want to be long term

That's it. If there's an opportunity to step closer to where your strategy is pointing you should try to take it, even if there's a quick and dirty option available.

It sounds obvious but it isn’t

Simple as it may sound, it's sometimes hard for product people to take the steps they know are needed to improve

Making decisions that appear to delay features can be difficult to justify with stakeholders who have more focus on short term financial performance when easier paths to value are available
A false sense of urgency is the biggest risk I’ve seen play out more than once. This occurs when a team is pushed to implement a capability using the shortest route possible - usually leveraging technology that wasn’t designed for the purpose.
Not knowing where you’re heading is another genuine risk. If the product and development teams don’t have an understanding of the longer term company vision and objectives then it is hard to know whether their decisions are moving them in the right direction or not.

These triggers can lead to short-termism on an individual decision basis, however it's collectively where the impact is most apparent.

Multiple small decisions have a major impact

Knowing why this simple rule is so fundamental requires an understanding of the power of iteration. Although each small decision may appear to have isolated impact, the combination of months or years of 'tactical' decisions can be crippling

A previous employer had a desire to move into the web, however due to a strong push from sales they took the quick route of prototyping and building their new scheduling interface in the existing rich desktop instead. This missed a huge opportunity to establish a more modern web platform which would have set the precedent for the migration to web that they needed for long term growth, instead the decision committed them to significant further investment into a desktop application which they wanted to move away from.
In another business I once encountered the legacy business rules engine had been incrementally added to to the point that it was not designed for the range of purposes it now met. Rather than using the creation of new products as an opprtunity to build out a well architected replacement, they kept creating new features leveraging on the old one. The resulting maintenance needs then slowed them down and added more pressure which made it even harder to move away as time went on.
A database company I worked for created a script based prototype to manage multi-server synchronisation. Rather than use this as a starting point to refractor and create a robust product, the quicker path was taken to progress into full production with a resulting mass of maintenance and testing challenges that slowed innovation elsewhere and committed more development and testing effort to maintaining a script based solution.

Each of these decisions probably seemed sensible in the context of the individual event. It is the combination of repeat decisions of this nature that can leave a company two or three years down the line with a mass of unmaintainable code and a sinking feeling when looking at how they have progressed against their longer term plans.

The first step in the right direction is the hardest

The good news is that the same principle works in the opposite direction too. Each step in the right direction builds on the last and accelerates progress towards a long term goal.

A former team of mine were delivering a capability to track customer segments from a marketing database. The shortest route would have been to use existing segment definitions from the legacy document store for their selection criteria, however they knew that long term we wanted a full segmentation tool in the web. Creating a very simple definition API capability to serve the web allowed the team to deliver a basic feature, and at the same time break one of the biggest technical barriers in our larger web migration.

The key here is that in itself this was a limited piece, but paved the way for further steps. There was an overhead in some extra effort over the easier option, but the reward for this was that the next feature that needed segment capability in the web had a great start to build on. It would have been hard to justify anything other than progressing the capability when addressing future needs. If instead we’d taken the easy route we’d still have been at the 'foot of the mountain' with the temptation to again take the easy path the next time a need arose.

Not every step is forwards, just don't go backwards

I’m a pragmatist and I know that not every decision provides the opportunity to progress longer term strategy. Even indirect steps can help as long as they don’t take you backwards. Work such as having to fix up legacy code, add a feature to stay competitive or address burning customer needs will always need prioritisation.

The problem is when the temptation then comes up to build a brand new feature on that legacy code, or push that prototype into production, as it’s quicker than biting off the architectural or product changes you know are needed. Taking the easy option here isn't just missing a change to move forward, it's adding to your problems and making it harder to progress in future. If you're facing such a decision I recommend that you ask yourself whether you're missing an opportunity to move in the right direction - and be honest about the answer. Your future self will thank you for it.

Photo by Vladislav Babienko on Unsplash

Setting Challenges to Drive Innovation

2021-07-19T20:29:00.001+01:00

Establishing an innovative culture has grown to be something of a holy grail in modern technology companies, with the goal of encouraging innovation a constant presence in white paper reports on CEO priorities. Yet building an innovative environment is not as easy as it looks - in fact the challenge of "fostering an innovative culture" is such a problem that it was cited as the top barrier in this survey on innovation.

While the mantra of Facebook may have once been "Move fast and break things", few of us have the luxury of unconstrained innovation with limited responsibility (the 'r' word even caught up with Facebook eventually) and the conflicting pressures of desire for innovation and a need to deliver operational concerns can be unhappy bedfellows.

For most companies the idea of completely unconstrained innovation is a difficult one to sanction

Stakeholders want to see value. There may be some nervousness around allowing a team to go 'off roadmap' and so some level of direction is sensible in early experiments to provide reassurance that the team isn't just having fun
Time is money and as a technology leader you don't want to be seen as wasteful
Developers love technology and a big risk in allowing open innovation is an output that is little more than technology for the sake of it because someone wanted to try out a new toy

So how does a leader take steps to encourage innovation in their development teams without running the risk of a pointless blockchain integration? The best way I've found to introduce a more innovative culture, whilst maintaining a structure focussed around clear business value, is to frame innovation efforts through setting challenges.

A Multidimensional Problem

A few years ago I was facing a tricky problem. It was in the early stages of creating a new employee engagement product that, if done right, would replace a number of bespoke existing platforms and form the foundation of future company strategy. What was apparent from examining the existing systems we were targeting was that each had it's own highly customised organisational hierarchy that had been built into the database schema.

Most systems were based on a fixed database table hierarchy with a defined organisational levels specific to the management tiers of that organisation
One organisation had much more complex hierarchy (to the extent that on presenting it to us the company representatives gave up three layers in and wrote 'Here be dragons' underneath) so a looser team structure had been implemented, but this was so loose that identifying membership of lower level groups was extremely challenging due to the nested structure and aggregated reporting was a frightening prospect.

The CTO advised me to implement an arbitrary number of fixed hierarchical levels and try to map all customers to that. This was at least a straightforward approach but even some existing customer lists would have struggled to map into it and it didn't feel like the best starting point for an important technology platform.

I decided to present the challenge to the team as an opportunity for innovation. Initial research spikes pulled together info on all of our existing system hierarchies, and I then presented these back to the team with the challenge

Establish a system that can support all of our reference hierarchies while still allowing a performant way to identify members of each group and aggregate query reporting

Now inspiration rarely comes while staring at a problem, it usually comes later when performing routine tasks and allowing your mind to wander to make the necessary connections. So it was that an answer came to me while walking back from collecting a takeaway meal. I wasn't necessarily expecting to solve the problem myself so I excitedly mocked up the data structure in SQLServer to confirm that it worked and headed to work the next morning rather pleased with myself to be able to present a solution to the innovation challenge. As soon as I got in the team were at my desk eager to explain how they had (also) hit upon a solution. I couldn't help a wry smile as they sketched out on the white-board the exact model that I'd mocked up the night before.

The result that we'd independently landed on was a simple, powerful and flexible model that provided a solid basis for building the product user hierarchy around and has allowed the platform to support a wide range of blue-chip enterprise company structures.

Making it part of the process

By way of a more recent example - at the end of each quarter in my current organisation we devote a week to innovation. While the CEO is keen to encourage an innovative culture there was an initial concern around making sure the work was valuable - it is after all a small company and development time is precious. Setting challenges has been a great way to frame these sessions to ensure the team can input ideas, whilst at the same time driving towards a genuine business problem uncovered by our user research.

On the first occasion the challenge was to improve the initial impressions of a user hitting the landing page of our web application. We collected ideas not just from R&D but across the entire business and then combined these into a summary page with a truly novel communication recency visualisation.

In the most recent innovation sprint I set the challenge of making it easier to provide reporting to a senior manager who did not want to have to log into our system even to view a dashboard. I used the 'Crazy-8s' technique to generate ideas this time in an attempt to flush out more diverse and lateral ideas from the team. The results involved approaches which took advantage of our existing capabilities in new and interesting ways that I hadn't previously considered, such as adding reporting widgets to our own drag-and-drop email editor to support mailable performance reports.

On both occasions we generated a wealth of potential ideas, but the most important aspect was that the final solutions weren't based on just one person's idea but on the merging of different suggestions into a novel approach that could then be confidently taken into the mainstream development process.

Not all plain sailing

Setting a challenge for innovation is in some ways surprisingly easy - as long as you are able to sufficiently define a problem that is valuable to solve, then it's really a question of explaining the problem and presenting it to the people involved. There are some pitfalls to be aware of as you progress.

You need to be solving a real problem. Manufacturing a persona or inventing a problem statement may generate ideas but not useful outcomes. A few years ago I ran an innovation workshop against a challenge that we'd hypothesised existed for a user group, but we lacked evidence that it was a real concern. The result was a confusing workflow - the users didn't have the problem so didn't understand when we presented them with extra steps in the workflow to solve it.
Don't expect a perfect outcome 100% of the time. If a challenge is trivial it is not really a challenge, but a non-trivial one may not have the simple solution you were hoping for. All innovation is based on the assumption of having to learn from failure, and I advise having a back up plan to re-frame the challenge or consider a sub-optimal approach if an elegant solution isn't forthcoming.
Don't expect the solution you'd already thought of - when preparing challenges it's incredibly hard not to pre-design your own solutions. While you may have some ideas the whole point is to get wider input and let ideas bounce off each other. If your innovation processes are a thinly veiled attempt to push through your own solution ideas more quickly then don't expect to engage your team. In my most recent innovation exercise one potential approach that I'd thought may come up was rejected by the team as 'it wasn't really innovation', it was a straightforward development that just needed prioritising.
Be prepared to throw away the output - the result of setting innovation challenges is learning, not code. Even if a solution is prototyped please ensure to thrown this away, treating prototypes as early product never ends well and again the team are less likely to be engaged if your innovation efforts are an attempt to short-cut production developments without the rigour of proper process.
Be prepared to go through the 'groan zone'. If you are encouraging truly divergent thinking around a problem then you risk hitting the point where everyone gets slightly frustrated and feels like you're not narrowing on a solution. This is a natural consequence of really opening up your scope, if the challenge has been defined well then the process will naturally converge on a subset of ideas to progress.

An approach that grows as you do

If encouraging innovation in your organisation is on your radar but you're not sure where to start, I highly recommend establishing some innovation efforts based around setting challenges. While more open innovation may be the long term goal, working within the constraints of a known challenge addresses a lot of potential early concerns

Senior managers are more confident that innovation is driving towards a genuinely valuable goal.
The teams involved have the confidence to do some truly divergent thinking around the problem based on the outcome being a valuable one

As confidence from all parties grows in the value of such activities, you can make the challenges wider in scope and more ambitious. Keep progressing in this way and at some point the scope of the challenge set, and the aim to simply deliver value for your users, become one and the same.

References

My introduction to leading by setting challenges was through Tim Brown of IDEO's teaching such as this course and I highly recommend it for anyone stepping into an innovative leadership role - "Leading for Creativity"

Image - probably the ultimage innovation challenge, the Enigma machine. Wikimedia - https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/OperableEnigmaAvailabletoMakeEncryptedMessages.jpg/1024px-OperableEnigmaAvailabletoMakeEncryptedMessages.jpg

Exploratory Hypothesis Testing

2021-06-21T21:41:00.004+01:00

A challenge most of us face at some time when working in software is the pervading fear that everyone else is doing it better than you. It's far too easy to fall into the trap of believing that everyone else is diligently applying the latest methods and techniques while you're stuck fighting the day to day challenges that dominate your time. Spotify are an excellent example of a company whose posts and content imply an purist agile process nirvana, where anecdotal reports from the trenches reveal a far more pragmatic set of working practices that face just the same challenges as everyone else.

The most effective tactic I've found to address the risk of this kind of paranoia is to network with peers. It doesn't take long in a room full of people in similar roles to appreciate that your challenges are no worse than others', and few have the luxury of applying the idealistic techniques of the textbooks and corporate marketing content. I experienced an excellent example of this a lifetime ago (well pre-covid which feels like the same thing) during a product management peer 'un-conference' discussion on Hypothesis Testing.

A False Hypothesis

The format of the 'un-conference' was based on attendees posting their own topics for open or semi-structured discussion sessions - and one of the most well attended was on the subject of 'Hypothesis testing'. My discussions with people prior to the session revealed this as a subject that qualified as an area of paranoia among product people - it was clearly something that folks thought they should be doing. Most product people I spoke to who intended to go to the session fully expected the other delegates to be more comfortable than them with the topic, and wanted to see and understand how others were approaching it.

What actually emerged from the discussion was that here was a technique that clearly more were talking about than were actually doing themselves:-

Very few product people were adopting hypothesis testing - At least in a formal sense in their day-to-day work. In response to the question "Who here is actually doing structured hypothesis testing?" only about 3 hands went up with any conviction, out of a room of I'd guess between 20 and 30.
Attempts to implement it hadn't stuck - even when the discussion host claimed to have introduce a structured approach in their product team, details emerged from another attendee from the same company that the team in question hadn't persisted with the approach after the instigator had moved on.
Few people were clear how to do it - as the discussion progressed it became clear that few were confident in how to go about establishing a structure for product hypothesis testing. Most folks in the room had a good grasp of what a hypothesis was but there was a lot of uncertainty around how to actually construct a formal approach and so few had actually tried anything.

This shape of everyone assuming everyone else is succeeding with a technique while few actually are is one I've seen before. The idea of Product people writing natural language BDD tests to drive automation was hugely popular a few years ago yet everyone I spoke to that had attempted it saw little benefit in essentially asking product roles to write pseudo-code. The reality is that implementing any new structured approach, particularly one that involves adoption and input from other roles, is a significant undertaking that a lot of folks simply don't have time to do.

Do you need structure?

Given how much easier it is to write about how good something is than to actually show it, it's understandable that such situations occur, but where does that leave the majority of folks who don't have the time or autonomy to drive the implementation of new methods?

For me it starts with an understanding that you don't need to implement a formal approach to get value from experimenting with a technique. If you build flexibility into your process then applying new ideas in context can be done in an ad-hoc way when appropriate to the context of the problem at hand.

The discussion in the conference room was based on an assumption that adopting a hypothesis based approach required a defined structure and process to document and process hypotheses and testing outcomes. People discussed hypotheses as a separate entity from stories, spikes and other backlog work. There was lots of talk around where people should document their hypotheses - with spreadsheets and confluence being mentioned. While this may be integral to the work of a devoted UX researcher testing the impact of isolated changes in the user experience, for many product people, having another separate list to focus on may not be practical. It's enough to be prioritising between progressing the feature roadmap, maintenance work, bug fixing and ops/infrastructure improvements without having a separate list of hypotheses to juggle as well.

Just do it

My suggestion to the room was, rather than fight a battle to introduce a new structure into already busy teams - a more pragmatic approach is to introduce work into the existing team backlog to validate hypotheses and test assumptions. In my current organisation we took the approach of creating a backlog item simply called "Work". It's not a bug, or a story (we have those as well), but simply a loosely defined work item of flexible shape. This could be investigating an area of concern, running a technical research spike or gathering evidence to prove/disprove a hypothesis - anything that will take the team forward in knowledge and learning is a candidate. In this flexible way documenting a hypothesis and the steps to validate becomes part of the acceptance criteria of the individual work item, rather than on a separate list somewhere. The learning goes into the 'research' area of the team wiki and the relevant work items are created to follow up on the evidence gathered.

Adding research items into team backlogs in this manner provides a low key, defensible route to incorporate hypothesis testing into a team's existing processes, when time and resources may be stretched. These can be standalone investigations or form part of the initial research to support decisions around a larger development. The approach handily circumvents any accusations of arbitrarily forcing in new processes - after all it would be hard for anyone to argue against taking the initiative to identify and test that your assumptions around a development are valid.

Work works

I've spent a lot of my career arguing that tests don't need to be formally structured and documented to get value from them, and for me hypothesis testing in product is no exception. As with many methods, actually starting small and simple may be a better way for many to start given the barriers that can be thrown up when trying to introduce large changes. Additionally an exploratory approach actually accommodates better for context as exploration naturally shapes itself around the problem at hand.

At the risk of seeming to advocating a method to avoid other methods - I can recommend having a loose backlog item of 'work' (or if you insist on a more specific name, maybe 'research') as an option in your backlog tracking system for exactly this reason. Investigation, testing and exploration can take many forms, and flexibility of tools and techniques in context wins out over formality in my book every time.

Thanks to National Cancer Institute for this Photo on Unsplash

Driving a Change in Product Direction

2021-04-07T21:28:00.002+01:00

In my last post I examined some lessons learned in driving a change in career. Sticking with the subject of driving change, in this post I examine some lessons learned from my recent work initiating a change in product direction.

Since I joined my current company in 2019 the end user capabilities of my product have been almost exclusively served through a desktop application. This type of application provides users with a lot of power, but it is challenging to develop and much harder to restyle than a web-based application. While the easy option would have been to continue developing this capability, we'd already seen some early signs of negative feedback based on perception compared to a web product. It was apparent to us as a company that we needed a shift in direction, but the challenge was that so much of the user experience was tied up in this application that there wasn't a clear path to the web without a major rewrite.

Re-evaluating the product goals

The first step to initiate change was to evaluate our existing user goals and whether our current approach was the appropriate way to achieve them. The product is based on a highly powerful and flexible data engine and the user experience does expose that strong data capability to the user. From speaking to customers in an early training course it seemed that they were less comfortable with exposure to database concepts than was needed to get the best from the software. I hypothesised that a shift of data skills out of marketing teams, and the advent of an increased number of digital marketing channels, had shifted the goalposts in terms of our target audience.

Further research with our team helped to validate this hypothesis.

Listing out and profiling a representative set of our user base with the customer services team gave a clear majority group of users who had stronger creative and testing skills but were less comfortable with database concepts
Running a whole company workshop to create some representative proto-personas was a revealing step which opened up the discussion around our user base and the importance of working towards a simpler user experience
Attending more training courses and speaking to new users provided invaluable insights into their early experiences of using the product and which concepts they found challenging
Conducting research interviews of both existing users and representatives from our target market reinforced the validity of our personas and the jobs that those roles were using our software to achieve

The outputs of this process provided the justification I needed to drive a change not only for technical reasons, but also to push towards a new, simpler customer experience.

A strategy for change

Some larger companies needing a product refresh will spin up a parallel team and instigate a rewrite in a new stack (see my post on the perils of rewrites for the problems that this can present). With a small development team actively supporting live software this was simply not an option for us.

What we needed was a strategy that allowed us to progress towards a different shape in a way that didn't undermine the value that we were already delivering. We needed to shift the focus of our application away from the desktop, and reduce the need for understanding database concepts, while maintaining a valuable product shape along the way. After all, identifying the need for a change in direction is great but it is of little use if the path from source to destination is not navigable.

Incremental Steps

Trying to leap from starting position to end goal without any valuable steps in between leaves you very exposed if you fail to hit that goal first time. A key for me in driving effective change, in pretty much any context, is through the agile principle of delivering valuable, achievable increments.

When moving to new technology the first deliveries may be quite limited when compared to existing features, but this simple start is justified if it establishes a solid point from which to drive a change
Showing a small amount of value regularly provides stakeholders with evidence of your progress and it's surprising how quickly incremental value can grow
Achieving frequent valuable steps is also more motivational for the team than aiming for a distant goal
Finally if the goalposts move mid-transition you always have a solid current position as a base to pivot from to shift direction

The strategy I settled on in this case was to provide new turnkey reporting capabilities in the web. This would provide a slice of important value, reduce the need to use more raw data tools and maintain a coherent platform with each step taken. Keeping these coherent increments is a challenge but it means we're finding the balance between effectively delivering new value and driving strategic change at the same time.

Prioritise Aggressively

Emergent product decisions often involve a trade off between long term plans and tactical needs. Too often the result is that your dreams of change remain just that, at the expense of a constant stream of emergent priorities. It can be challenging but achieving each valuable change increment may require deferring other needs that others may see as more important at the time.

I'd argue that there's no perfect model for making these decisions. Deferring anything that impacts on the change you're trying to achieve without incurring significant cost elsewhere will prevent your efforts from stalling, but defer too much and existing customers or stakeholders may get frustrated. Having a strategic goal in mind gives you a framework for decision making that allows you to make sure you are always moving in the right general direction. Again delivering in increments is also key here as it means that you can allow time to take a breath and focus on addressing some tactical concerns between each step.

Trust you can get there

The biggest fear faced by most senior software professionals I know is getting it wrong. Despite all our efforts to base decisions on evidence, it's clear that for anyone having to make significant strategic decisions there's rarely a universal right answer on when and how to instigate change (If there was then why are so many successful entrepreneurs' closets full of failures ). As the numerous tales of great products that went stale will tell you, not making the decision to change can be the worst decision of all. Even so, in the early stages the idea of achieving any sizeable impact can feel a distant and intimidating prospect.

I find that if you build a great teams and get them on board with a vision of what you can achieve, then you can trust in your collective ability to deliver. This is for the simple reason that a great team will challenge your ideas and simply won't be fully engaged if they don't believe they are achievable. While there are no promises in the outcome, if you are seeing genuine engagement behind your strategy then there's every reason to be confident that you can elicit real change. As we release the first capabilities in our entirely new web application this month after a stupendous effort from my team, this is something I can attest to first hand.

References

As a side note, I know that some are advocating that the Jobs To Be Done (JTBD) framework has rendered proto-personas redundant. In this case I believe that personas provided a far more effective mechanism to communicate our situation and convey the need to rethink our user experience based on the skills and desires of our users - this article provides a useful reference point that supports my experience on this https://www.nngroup.com/articles/personas-jobs-be-done/

Photo by Benjamin Combs on Unsplash

Turning from Testing - a Guide to Changing Careers

2021-02-08T22:21:00.001+00:00

The decision to change course in your career is one of the most difficult you can make. Taking on the risk of doing something new is an intimidating option compared to the comfort of sticking with the familiar. When this also involves leaving behind a path that has provided you with success in the past it is particularly daunting, which is why far too often we put off making changes until it’s too late.

5 years ago I was a relatively successful software tester. I enjoyed being a tester and leading test teams. As well as my experience in the role I also had the confidence that came with being a member of an engaged professional community of fantastic, enthusiastic people. I'd spoken at conferences, I'd helped to write books, I had a lot to lose leaving this behind. But when my company was sold, and eventually wound down, I faced a difficult decision. While testing had served me well, I was already experiencing limitations associated with the title. Should I stick with the role I knew and loved or change path in an attempt to open up more opportunities?

Re-evaluate where you're heading

Contrary to what many self-help authors will tell you, the first important step in achieving change is not establishing a goal. It is discarding one. When working towards the things you may have seen as aspirations in the past it's easy to lose sight of the fact that the world shifts around you, and sometimes the role you were aspiring to becomes less valuable or simply less viable over time.

Despite being well placed in a testing career 5 years ago, I was also facing challenges with the job description. The advent of self-managing distributed teams had seen testing evolve towards a specialism within development teams rather than it's own vertical requiring senior leadership. On top of that my location in the West of England, and preference for working in small agile companies meant that attractive senior testing opportunities were limited. I made the difficult decision to move away from testing as a job description and try another path.

Being honest enough to re-evaluate your goals and change tack is a really difficult process. It's easy to fall prey to the sunk-cost fallacy and stick with the role you feel that you've invested in, particularly if that success extends beyond your employment into being part of a professional community. Writing this blog, for example, I'm acutely aware that writing now I lack the clear target audience I once enjoyed. Accepting that former goals may no longer be the right ones is a brave step, but it's the first one in achieving valuable change.

Find a new path

Identifying that change is needed is the first step, but it can be hard when you don't have an obvious destination in mind. I recently chatted with a tester who was in a familiar position to me - he was looking for work and trying to decide whether to push on with another senior testing role. Just this week I saw a tester pose a similar question on twitter relating to her career 'crossroads' of whether to stick with testing or change path. It's not a given that changing role is the right decision - for many people sticking with their role and progressing and excelling within it will open up great opportunities, so moving path needs careful consideration.

Taking time over your decision is OK - exploring and finding whether a new path is right for you is a valid part of the change process
Talking to current and former colleagues in different jobs can help with understanding whether it's a good fit for your skills
If you want to try out a new role then contracting or consulting can provide a great opportunity to try something out without the stigma of 'job hopping' - and can also be a great way to put some new roles on your CV or resume to step away from a former job description
If you try a new role in a new company and don't enjoy it then there may be an opportunity to move back to something you are more familiar with - after all good people are hard to find in any role

The beauty of considering a change in role is that you can tackle it with a completely open mind, safe in the knowledge that you have a great set of skills to fall back on if you don't feel there's a more compelling option for you.

Set yourself a goal

If you decide that a new role works for you then establishing a long term goal can help to make stepping away from your achievements of the past more acceptable

Despite what numerous advocates of 'SMART' goals will tell you, a goal doesn't have to be that specific to be useful - to drive change you just need to establish a clear enough direction to inform you at any decision points whether you are stepping towards or away from it
Having a long term aspiration allows you to assess your current options in light of which one most aligns with where you want to get to
Establishing a long term goal job title can help you research the requirements of the role and the gaps you need to fill in your skills
Identifying new blogs, learning resources and professional communities is a great way to familiarise yourself with a role and what it takes to be successful

Over the last 5 years I've made decisions which, based on their outcome, may have appeared to be the wrong ones. In hindsight what was clear is that even the riskier decisions were ones that got me nearer to where I needed to go, rather than safe ones that stepped away from it. Taking on a hugely risky greenfield product as I wrote about in "Life and Death of a Startup" wasn't easy and I still feel a weight of responsibility for the outcome on a great team. The learning from it, however, was more valuable Product experience than any number of safer bespoke projects.

Don't be scared to step back to move forwards

When moving away from a role where you have depth of experience, it's not necessarily going to be the case that the most progressive step will be forwards.

It's naive to expect to move from a high level of seniority in one role straight into another role at the same level without needing to rebuild some foundations.
Sometimes a step down is needed to allow you to get in and prove yourself to a new organisation. I learned this lesson many years ago when I took a step down in responsibility in order to learn and grow my career as a tester in an exciting startup.
Whilst it can be hard to take a step back in salary or role, the quicker that you get onto the right path the quicker you can start progressing away from the associations with your current position that are the reasons for wanting to change.
Don't underestimate how much of your experience is transferable. Most decision making roles in software development have a huge amount of overlap - something I realised early on in my decision to move from Testing to Product and wrote about in "Tester, PO, Armadillo" - so you already have a great base to build from in a number of different roles.

I've stepped back both in terms of role and salary more than once as a way of consolidating learning and establishing a new base to build from, and while it may not always be convenient it can be the best way to start the process of change.

Trust in your ability to get there

In the world of software, rapidly innovating is a key factor in competitive advantage and this relies on the ability to make mistakes. This principle applies just as much in personal roles as it does for product innovation. Driving change and creating opportunities is a mindset that can be just as rewarding personally as it is organisationally, and in the same way the biggest rewards will come with an element of risk. To handle when things don't work out as you planned it's important to believe in yourself and your ability to learn and grow again to get to where you want to be, it's tempting to revert to the familiar when you encounter a setback.

I'm now two years in to what for me what could have been seen as another risky move, but again it was an opportunity that aligned with where I wanted to move professionally. The way things have gone so far certainly support this, but I'm acutely aware that the future holds no guarantees. What I am confident in is that changing path was the right decision for me and has opened up opportunities for me that I simply wouldn't have had if I'd stayed with the safe option.

Recognition - the leadership secret weapon that drives communities

2020-11-16T22:19:00.003+00:00

A couple of weeks ago a change came over me at work. I felt more engaged with what I was doing. I was more motivated to overcome challenges that the day before had felt overwhelming. I had more purpose and confident in my decisions. What, you might ask, was the driving force behind this burst of positivity. Had I started some new medication? Was I trying out a new brand of coffee? Had I had a pay rise? No - in actual fact the reason was far simpler than this - I'd received a compliment on my work.

Proving the power of recognition

You can't spend 3 years leading the product team in an employee engagement company, as I did, without learning a few things about motivation. One of the key lessons that I took away from my time in that role was the vital importance of recognition to employee motivation. The statistics around the importance of recognition are easy to find, and compelling.

The many figures quoted in this post include evidence that recognition both reduces employee frustration and increases engagement
This article by Gallup also contains some interesting figures, such as "employees who do not feel adequately recognized are twice as likely to say they'll quit in the next year"

The power of recognition is such that blue chip companies will happily pay six-figure sums for software just to provide a way for employees recognise each other for their work. Entire application frameworks exist to support peer recognition, and these features are now leaking into our mainstream collaboration and professional networking tools such as in the Microsoft Teams "Praise" feature or LinkedIn "Kudos".

A failure to recognise, and recognising failure

Given that employee recognition is such a powerful force in motivation, it is surprising how easy it is to build a culture that overlooks it. The absence of positive recognition is a depressingly common problem

This study quoted 82% of americans feeling that their employer didn't recognise them enough at work
Another one quoted 70% of employees say that motivation and morale would improve “massively” with managers saying thank you more.

Even worse than a mere absence of recognition is when cultures evolve to recognise people not for their achievements but for their failures. In the situation where achievements go unnoticed but mistakes are highlighted it's not difficult to see how employees start to question their value to the company. I wonder how many individuals have only truly been told how much they were valued after they handed in their notice.

Practical Examples are Easy to Find

Despite the impressive statistics and powerful research around the presence, or absence, of recognition, it's more immediate and personal observations that I find more interesting. In examining the the behaviour within ourselves and our communities, demonstrations of the power of recognition are never far away.

By way of a small recent example - I've struggled during the Coronavirus lockdown to engage my kids in pracising their musical instruments. They will happily practice to work towards a concert or performance which will provide the reward of recognition from grandparents or school friends. Remove that incentive and it became immeasurably harder to engage them in their practice. This doesn't just apply to kids - I also play cornet (bit like a trumpet) in a band and have struggled to motivate myself to practice without the driver of upcoming performances.

Recognition is the Engine Driving Communities

A more significant demonstration of how powerful a motivator recognition can be lies in professional communities. If we look at the way that professional communities operate and interact then we can see recognition as one of the primary driving factors. Individuals will freely give huge amounts of valuable time and effort in exchange purely for the chance of professional peer recognition, and it is this motivation that powers the vibrant communities that us software professionals enjoy.

Of course there are financial elements that support a community, such as through ticket sales, sponsorship and consultancy, but these are tolerated as necessary rather than celebrated. A professional community is not a money based market, it is a recognition based one. Tweets, shares and references are the currency of community members, and these cost nothing.

Whereas people will gladly give hundreds of pounds worth of time and effort in exchange for recognition, this time is given at their convenience when perhaps family commitments are finished for the day (my younger children are in bed while I am writing this post). Vying for personal finances, on the other hand, comes in direct competition with family expenses and is therefore harder to justify. Similarly obtaining funding from employers for professional membership, when much of the value gained is in personal recognition, is a hard sell.

Be careful what you recognise

I hope that this post has convinced you that recognition is too important to ignore. Before you run off and implement an expensive annual recognition programme, here are some points to bear in mind

Recognition is too important to leave to an annual review. Achievements are best acknowledged immediately so the receiver associates the recognition with the event. Better to recognise quickly and often than to save praise for a few lucky souls once a year and risk leaving everyone else demoralised.
Be careful what you recognise - sure it's important to acknowledge when people put in extra effort, but if you're recognition is limited to when folks work late or weekends then you risk building a culture of presenteeism where working long hours is valued more highly than achievement.
Recognise improving on mistakes - everyone makes mistakes, if you want to encourage a blame free culture then acknowledge mistakes but recognise when people proactively resolve them too. More importantly to avoid a "crisis culture" - recognise in future the improvement that people make to avoid the mistakes in the first place.

So recognition, like any influential force, needs to be applied in the right direction to avoid doing damage. But given that it is totally free, powerful enough to improve productivity and drive entire cultures, the greatest damage would be to underestimate the importance of recognition in the first place.

References

Some good statistics on the impact of recognition in this Gallup post - Recogniton, low cost high impact
And even more in this useful stats roundup - 25 Great Statistics About Employee Recognition
Two useful posts on the impact of recognition on Morale - Harvard Business Review - Recognition and Morale and Recognition statistics from Bonusly Blog
A good summary post on the problems of "Hero Culture" here - https://www.linkedin.com/pulse/six-ways-your-companys-hero-culture-killing-dan-kimble-mba/
And here's one that introduced me to the term "crisis culture" - https://www.techwell.com/2012/08/hero-culture-or-crisis-culture

Innovation Stories 2 - The Locked Shop

2020-09-22T21:13:00.007+01:00

This is the second of two true stories I’m sharing in which children exhibit phenomenal lateral thinking, and in doing so demonstrate some fundamental principles of innovation. In the first post a story of a class spelling test showed how "Innovation Loves Constraints". In this post we move to a village in Ghana and a tale from my brother where a kid shows, not necessarily legally, that "Innovation Loves Opportunity".

I like this following story. Whilst the protagonist is very clever and demonstrates a simple solution to take advantage of an opportunity he identifies, his solution was illegal and he got caught so I can recount the story happily with no sense of envy at the genius of his creativity. The names are made up, I'd like to say this is to protect anonymity but actually it's because I can't remember them.

The Shop

My brother lived as a volunteer in a village in Ghana for a couple of years in his youth. Many of the shops in his village were simple wooden sheds with a single front door and no windows. One such shop in the village sold, amongst other things, a variety of candy and sweets. The owner, let's call him Abraham, would unlock the padlocked door to the shop each morning, put out the displays that stood outside the shop, and man the shop all day. On the rare occasions that Abraham did take a break someone else watched the shop for him, such that the shop was under constant supervision. At the end of the day Abraham would put all the boxes and stands back inside, checking each as he did so. He'd then lock the door by snapping the padlock on it, a padlock to which Abraham kept the only key.

Each day that this happened a boy, let's call him Daniel, would stare longingly at the items in the shop and wish that he could afford some of the treats inside. Sadly sweets were expensive and Daniel was poor, so he was limited to looking forlornly at them each day with little hope of ever getting any.

One morning, however, Abraham arrived at the shop, unlocked the padlock and opened the door to find that a load of his stock was missing. The door was in-tact and unmolested. There was no sign of any break in elsewhere, the walls, door and floor were all in perfect condition. The sweets had simply disappeared. The alert went out around the village, and before long a stack of goodies was discovered in Daniel's possession. He'd cleaned out the shop, but how?

At this point I challenge you to see if you can work it out yourself before you read on.

The Opportunity

What Daniel had done was to spot an opportunity. While Abraham was watching his stock, and his shop, all day, there was one thing he wasn't watching. The padlock.

Daniel knew exactly what type of padlock it was and managed to lay his hands on an identical one, to which he had the key. After Abraham had unlocked the shop and placed the padlock to one side, Daniel simple crept in and replaced the open padlock with his own. Abraham locked the shop that night with absolutely no idea that the only person with access to the shop was now not himself, but a small boy with a key, and a very devious streak.

It was a simple task for Daniel to sneak along that night, unlock his own padlock and clean out the shop. The icing on the cake was locking the shop up again with Abraham's original padlock so that there was no sign from the outside that anything was amiss and allowing Abraham to open up his shop as usual the next day.

Creativity doesn't always create

Did you work it out? Well done if you did. It sounds paradoxical to say that creativity isn't always about creating, but as this story demonstrates, sometimes it is as much about setting an opportunity and applying an existing idea in a novel way. Daniel wasn't thinking about how to get into the locked shop, his idea was to use the fact that the shop was inevitably going to be locked to his advantage. The best innovations are often the most annoying, mainly because they are very simple and you didn't think of them. The innovator simply saw an opportunity and applied existing technology to come up with a 'good enough' solution.

As a relevant aside, my father in law revels in telling me that he knows the person who invented the retractable crowd barrier - essentially attaching a retractable car seatbelt on top of a metal pole - and made millions. I have no idea if this is true, but as someone who is more of a constraints driven innovator than an opportunistic one, it's a galling tale to hear repeatedly from the man whose daughter you are married to.

Spotting multi-million pound product opportunities like this will sadly continue to elude most of us. What the two tales I've shared in these posts ably demonstrate, is that it doesn't take great wisdom, a wealth of experience or a creative gene to identify creative opportunities that are beautiful in their simplicity. It therefore follows that maintaining a culture where as many people as possible feel able to contribute to innovative activities, at least maximises the chances of spotting opportunities when they do arise.

image: www.africastories.org

Innovation Stories 1 - The Spelling Test

2020-07-19T22:38:00.000+01:00

One of the great myths of innovation is that you need to be some kind of genius to come up with great ideas, however nothing could be further from the truth. In this post I'll share the first of two real life stories where kids have displayed amazing levels of ingenuity and lateral thinking. Each story also perfectly demonstrates an important principle of innovation - in the case of this first story - that Innovation Loves Constraints.

Innovation Loves Constraints

One of Burkus's 10 "Myths of Innovation" that I wrote about in my post "A principled approach to innovation" is that innovation is inhibited by constraints. Burkus successfully argued in his book "The Myths of Creativity" that in actual fact Innovation can result from trying to work with constraints. It is in overcoming constraints that some of the most ingenious and creative thinking is brought to bear, which simply wouldn't be necessary given unlimited capability, time or resources.

This story, a memorable event from my childhood, shows that an acute awareness of your personal constraints can prompt ingenious thinking from the unlikeliest of sources.

The Dictionary Test

When I was about 7 years old my class teacher decided to play a spelling game with the class. She took out a large dictionary from the bookshelf and explained that she was going to ask each of us to spell a word. To choose the word to spell we would play a game

Firstly we would choose a number between 1 and about 400 - this would be the page from the dictionary from which our word would be chosen
Secondly we would choose a number between 1 and 2 - this would be the column from the page from which our word would come
Thirdly we would choose a number from 1 to about 20 - this would be the position of the word in the column

Each child showed a mix of excitement or apprehension. While playing a game was exciting, we all knew that the dictionary contained a whole plethora or words that we didn't have a clue how to spell, like "plethora" for example.

As the teacher went to each child in turn the excitement mounted as we waited to hear what word we would have to spell. Each child's word was associated with groans (if it was easy) or gasps (if it was a tricky one), and in this way most of the class had their turn. Then the teacher moved on to Samuel.

Victory from the Jaws of Defeat

Samuel was a farmer's son and was not in any way academically gifted. It's safe to say his skills lay in other areas (I believe he now runs a successful farm) and he would be the first to admit that spelling wasn't his strong point. Samuel was facing a serious resource constraint - he had a much lower number of words in the dictionary he knew how to spell than anyone else in the class. Whilst I'm sure there was no cruelty in it, a distinct hush descended from the rest of the class when Samuel's name was called, as we all waited with baited breath to see what was going to happen.

The teacher asked Samuel for his page number

Samuel: "One"

At this point a murmur spread around the class. No-one had gone with page one, we all twigged that at least he knew that the first letter was definitely going to be 'A'. The teacher asked for his column number

"One"

Interesting...was that a smile we could see forming at the side of the teacher's mouth. The teacher asked for Samuel's word number

'One'

The teacher's face was now a full beaming smile

'Samuel - how do you spell "a"'

and like the victorious golfer knocking a winning putt from 3 inches Samuel replied

'a'

The room exploded. The kids were laughing and cheering, the teacher was laughing. Those kids whose numbers had thrown up "phsychoanalysis" level words were sitting head in hands in disbelief that 'even' Samuel had succeeded where they had failed.

In one simple, glorious action Samuel had ably demonstrated the relationship between innovation and constraints. The rest of the class had a fair chance of getting a word we knew so didn't bother to think in other ways about the problem. Samuel knew he had a very slim chance of getting a word he could spell. Rather than worrying about all the words he didn't know, he shifted his focus laterally to whether he could somehow make sure he got one he did. The solution came to him in inspirational fashion.

With over 20 years of working in software development behind me I still think this is one of the smartest demonstrations of lateral thinking I've ever seen, hat's off to Samuel he won the day that day, and the respect of 20 kids forever.

The Imitation Game

Along with the positive message around not letting your constraints inhibit your creativity, there's also a cautionary lesson in this tale, demonstrated by a boy we'll call Kevin.

Once the hubbub had died down in the class the teacher moved on to Kevin, who was the boy sitting next to Samuel.

The teacher asked Kevin what numbers he wanted

'One, One, Two'

Kevin smugly announced, folding his arms like he'd won the 'second smartest kid in the room' award.

'OK Kevin - how do you spell "Aardvark"'

And there lies another principle of innovation. Imitating other people's ideas only works if you deliver the same value as the original, otherwise you just end up looking foolish.

In my next post I'll share another story of ingenious and downright sneaky innovation from a child who very ably demonstrated that a good chunk of innovation comes from being able to see an opportunity that others don't.

Main photo by Ben White on Unsplash

Innovating from Home - Running an Innovation Sprint Remotely

2020-07-08T23:06:00.003+01:00

Last week I ran a fully remote innovation sprint. I'd been planning to run one for some time, but in my head I'd always pictured it as an 'in the room' activity probably involving post-its, and pizzas. Having made some key hires recently it felt like a group activity was needed to bring the new team together, even if on this occasion this meant virtually rather than physically, and an innovation sprint proved to be a constructive way to achieve this.

The Importance of Promoting Innovation

In recent years the promotion of innovation has become a real focus for companies seeking competitive advantage. In fact a 2020 survey of 750 corporate CEOs and almost 800 other C-suite executive revealed "Creating a more innovative culture" to be the third most important priority for both the European and North American responders.

Building such a culture is hard, and has many pitfalls. In my post "The Innovation Silo" I discussed the perils of restricting innovation to a few key roles and the risk on motivation for others. If the development teams feel that they are just being asked to overcome the practical challenges in delivering other people's ideas and prototypes this can be demoralising. It's important in promoting an innovative culture that everyone feels part of the innovation, so group activities and ideas gathering are important to give everyone creative input into a product.

A former colleague had first introduced me to the idea of 'Innovation Sprints' - where a team decide on and take on an innovation task on a fixed timescale in the form of a compressed agile sprint - a couple of years ago. This was something I'd wanted to try and so was pleased when the CEO and CTO in my current company were also keen to try this activity. Having made some key hires late last year this felt like a great opportunity to bring the new team together on an activity and provide some much needed team building in this period of forced remote working.

Setting off on the right foot

With any workshop based session, the kick-off is vital. People’s time is precious and to avoid skepticism they need to understand why they are involved and the what is expected of them from the start. Having all attendees connecting in remotely made it even more important to get everyone engaged with the activity to maintain momentum while working apart. With this in mind I invested more preparation in this session than I perhaps would for a physical workshop. The key elements of the kickoff were:

Why we were running the session. It seems obvious but when bringing such a wide variety of roles together and asking them to commit their time to a venture, it's important that everyone is clear why we're in the room and bought into the value of it.
How we would run it. This included a rough agenda (in our case covering 4 days) and also details of the channels and means of communication. For a physical on-site session a brief agenda would have been enough, but the remote element meant that it was more important for people to understand where and how to communicate and capture their findings.
Presenting the challenge. Innovation loves challenges, so a great way to present a subject for innovation is in the form of a challenge. I showed a video recording of a user research session where the subject explained how the right tool had grown to become the focal element in her team's weekly decision making. I then gave an open remit to the attendees to come up with ideas to help meet the equivalent need for users of our system. The challenge was literally a blank canvas to create a team's go-to place for weekly status reviews.
Gather ideas. Innovation isn't easily forced 'in the room' - inspiration tends to be more forthcoming when people have time to process the problem and then come together to make creative connections. With this in mind I'd prepped people beforehand with some vague details of the focus of the challenge to prompt some offline thinking. After presenting the challenge I gave folks 15 minutes to think, discuss and share ideas of how we could help the subject of the video achieve her goals.
Prioritise and target. In the absence of 'in the room' dot voting on Post-its, I collected ideas via Teams chat and added to a mindmap via screenshare. I used a Microsoft Form with a sort-order question type to allow everyone to vote on the ideas. The resulting top priority was something that overlapped very heavily with a development that was already scheduled for prototyping in the next full sprint. We wanted the innovation sprint to be a separate, self-contained effort so we agreed instead to progress with the next priority item.

This kick-off session ran for 2 hours, which felt like a reasonable duration to ask all members to attend. By the end of that time we had a clear target for delivery along with company-wide buy in on what the development team would be doing for the remainder of the sprint.

Getting things done

Off the back of the kick-off session the development team created a top level backlog item and collectively broke this down into tasks to share across the team. This involved a mixture of concurrent research and development activities.

Researching and user testing options for data and visualisation to help answer key questions
Standing up an API to serve data
Selecting client-side libraries and assessing both for rapid prototyping and potential production use
Exploring how to gather and aggregate the necessary data
Exploring production systems to confirm assumptions around the shape of customer data and identify anomalies.

Our intention was to establish a narrow working prototype if possible, but with a priority to capture learning around limitations and challenges that we'd need to tackle if taking the capability into a production feature.

After one day it became clear that, while researching different options was valuable we also needed to decide on an initial target design if we were to get a capability prototyped in the time available. We therefore mocked up a wire-frame of the best options we'd identified to that point, and geared development towards it, while concurrently doing rapid usability testing on the design with internal stakeholders to identify potential refinements.

By the end of day three we had the basic capability up and running and had iterated the visualisations based on the feedback. This left day four for final adjustments and writing up all of the learning that we'd gained from putting the prototype together.

As a final step in the process we brought the whole company back together for a demo and review. As well as reviewing the prototype, each member of the team presented on the contribution they had made to the activity and the learning that we'd gained.

What went well

Despite having run many innovation workshops this was the first time I'd used a full innovation sprint format, remote or otherwise, and I was pleased with the outcome. If I was to highlight the particular positives from the week they would be :

Everyone was involved. We managed to get most people in the company involved at least during the launch and wrap up sessions. Not only did we get the benefit of their ideas but also got to show how innovation is part of our core strategy and that that ideas can come from anywhere. Also all of the dev team were involved in contributing to the research and final prototype.
We gathered diverse ideas and prioritised. We gathered a broad set of initial ideas from across the business and identified a clear goal for the week from these diverse options that we developed into a working solution.
We balanced development and learning. One peril of innovation is that it's driven too much by technology and not enough by learning. Alongside developing a prototype, we also incorporated elements of rapid feedback and refinement of the prototype even in the short time available and also captured and documented a number of potential challenges to overcome in progressing the idea.
Running fully remote was better than partly remote. We have one member of the team who works fully remotely and sometimes he can be left out of the discussion if the rest of the team are in the same room. Having the session focussed on being fully remote actually meant it worked better for all participants.

What could have worked better

Despite a generally positive outcome there were elements of the innovation sprint which in retrospect could have worked better.

It was hard to keep the whole development team involved throughout. There were some moments where members had completed their tasks and didn't have new ones to pick up. At the same time the developer iterating the front end constantly had a lot to do. I think this was a pitfall of working remotely - if we had been working together in a shared space I think that the sharing of tasks would probably have been more fluid. If I did the same exercise fully remotely again I would be careful to more explicitly break up and share out the development tasks to ensure a balance across the team.
We still suffered from innovation silos. It's inevitable that certain roles will give more time over to thinking about innovation than others. It was clear that some of us, myself included, had already formed some strong ideas around the idea chosen and how parts of the experience might work. This made it hard for others to perhaps contribute as much to the creative part of the process as they would have liked. This is something I'll be wary of when we tackle this kind of activity again.
It was hard to get our ops expert involved. As the innovation was primarily through an existing channel there was little need for new infrastructure, therefore the member of our team who specalises in this area found it harder to contribute. This is something that we can potentially address in future, such as by tackling a more cross-cutting challenge.

These certainly didn't diminish the value of the activity, but they are learnings that will go towards improving future sessions and making sure everyone gets the same rewarding experience out of it.

Summary

I'm now scheduling in innovation sprints at the end of every quarter. I'd like to think our end of Q3 one will be a very different affair where we all get together in the same room. This is not just to overcome the challenges we faced, but more importantly because it's a great team and I miss working with them face-to-face. Plus I also I missed getting to order in pizza which felt like a big loss. In a retrospective session after the sprint we all agreed that, while generally successful, we missed the buzz and the banter that would have come from working on the challenge in the same room. I wouldn't hesitate to run another innovation sprint remotely if I had to, and I'm sure we'd look to address the challenges we encountered in the one just gone. But let's hope that, for far more important reasons that these, by the time we run the next one these aren't things we have to worry about.

Doing Press-ups - On Mental Health and The Importance of Awareness

2020-05-31T23:24:00.007+01:00

I was recently challenged by a friend on Facebook to do 25 press-ups (push-ups) per day to raise awareness of PTSD, anxiety and depression. In my typical 'once-a-tester always-a-tester' approach I decided to check out whether this was a real thing or just a secret new way to infer my banking passwords. What I found surprised me. The challenge is genuine and seems popular in Australia and New Zealand. The supporting pages that people have set up hold some frightening stats.

For example 45 per cent of Australians will experience a mental health issue at some point in their lives (The Push Up Challenge Australia)
14.3% of New Zealand adults (more than half a million people) had been diagnosed with depression at some time in their lives (Mental Health NZ)

Similarly frightening statistics can be found elsewhere too. Mental health issues are one of the biggest health concerns in Europe and the US.

In the US nearly half of people will experience a mental health issue in their lifetime and 5 percent of adults will experience a mental illness in any one year, equivalent to 43.8 million people. Mental Health First Aid
The latest in a one every 7 year survey in England (2016) found that 6.7 people of every 100 have attempted suicide in their lifetime (and that's just in a private home context not including prisons or other institutions) (Mind UK Statistics on Mental Health)

Mental health issues are now the third most common health problem in the UK yet, perhaps because of their very nature, these problems are much less openly discussed than other health issues.

Raising Awareness

It's perhaps a strange subject to write about in a blog on software development, and a difficult one too as it's such a complex subject. I'm writing this for two reasons.

One is to promote awareness and to encourage discussion of the subject. We need to raise awareness of mental health issues in the same way that we would with any other serious illness that is having such a widespread impact. There's a need to discuss mental health issues more in the software community simply because we need to discuss them more in every professional community and avoiding discussing it through fear of the complexity of the subject simply makes it harder for people who are suffering to talk about it.
The other is raise awareness that there are steps we can all take to improve the situation. There are things that we can potentially do to avoid or mitigate certain problems through the way we treat ourselves and others. This applies to us as individuals but is also particularly the case for leaders. Through more considered leadership we can eliminate practices in the workplace that may encourage or exacerbate mental health problems and help to reduce the frightening statistics that go with them.

Improving your own mental health

One thing that you may have experienced with the restrictions in place with the current pandemic crisis is a tangible sense of slowing down. Just today outside my local shop a lady said to me that she felt that everything had slowed down and it was a good thing, I had to agree. For many the recent restrictions have given them an opportunity to take stock of what's really important.

This need for taking stock is something I've been aware of for some time. A key moment came when I read The Happiness Advantage by Shawn Anchor which is a lightweight but readable introduction to the field of positive psychology applied to a work context. There are some strong takeaways in the book, an important one for me being that individuals can exert control over their own sense of well-being. Before I read the book I considered optimism to be a fixed genetic trait that for me meant inevitable periods of dwelling on the negative. Anchor argues that we can change our own levels of happiness and optimism, these aren't hard-wired, with real benefits for both mental health and productivity.

Here are some things that I've done, mainly since reading Anchor's book, to improve my mental wellbeing that I can recommend

Spend money on experiences not possessions. Putting your precious time and money into great experiences, particularly shared ones such as with family, rather than material goals will provide more happiness for your money, not least because there are many wonderful experiences out there that are free to access.
Stop pushing the next goal. As a good tester my goal was to be a good test manager, then I wanted to write a blog, then contribute to books, then I wanted to speak at conferences. Even at this point I was raising the bar and looking at the next step, should I be keynoting, or setting up a consultancy? Focusing on goals is a positive step but there's a risk that, rather than enjoying your achievements, you just raise your personal expectation to a new level of dissatisfaction.
Be wary of professional social media. For a time I enjoyed twitter and communicating with others in my field, however it can become addictive and drive unhealthy comparisons. A few years ago one of my children said they liked my new job as I wasn't on my phone the whole time. My sad realisation was that half that time I was actually scanning twitter as I didn't want to miss anything. Be aware of "The Facebook Effect", don't compare yourself to how others choose to present themselves as it's a long way from reality, and treat it like gambling - when the fun stops, stop.
Keep reminding yourself why you are fortunate. Every day for 4 years I've written in a notebook three reasons why I'm insanely fortunate. Good health, a great job, a wonderful family and home, colleagues I respect and enjoy working with. By thinking less about whether I should be keynoting or working on a book right now and more about how lucky I am with what I have, I find I'm less anxious about things I'm not doing.
Play music. At 35 I started to learn the classical guitar, at 40 I picked up the trumpet again for the first time since school to join my kids in a brass band. I now have two skills as an adult that provide focus, flow and pleasure, not to mention many psychological benefits including potentially making you smarter

These are personal things that work for me, but they are based on sound psychological principles. As with exercising regularly, different activities may work for different people. The important thing is to appreciate the value in regularly taking practical steps to look after your mental well-being as well as your physical.

Focusing on mental health as leaders

No matter how much we do ourselves, there will always be work influences which impact in ways that are outside our control and the workplace is a significant one for most people. The way that we lead can therefore have a big influence on the occurrence and impact of mental health issues. As the UK HSE website page on workplace stress states -

"Although stress can lead to physical and mental health conditions and can aggravate existing conditions, the good news is that it can be tackled. By taking action to remove or reduce stressors, you can prevent people becoming ill and avoid those with an existing condition becoming less able to control their illness."

So by reducing stressors from people's work leadership can have a potentially high impact on mental wellbeing. Even just being open about discussing mental health in the workplace is a good starting point. According to the ACAS mental health advice website

"If staff feel they can talk openly about mental health, problems are less likely to build up."

Happiness is Productive

The good news is that working to reduce stress doesn't have to impact productivity. Again referring back to the Happiness Advantage perhaps the key principle that's underpins the whole book is massively important in the approach to mental health in leadership.

"Happiness drives success, rather than success driving happiness"

Based on findings from positive psychology research at Harvard, Anchor proposes that happiness is a 'precursor to success' and actually drives success and higher performance rather than our achievements at work driving our happiness.

In order to promote productivity and encourage innovation and success, the last thing we therefore want to do is create a culture of pressure and anxiety. Instead encouraging a happy team is a stronger precursor to success. If leading towards team happiness is also a drive towards productivity and success then we can adopt a real focus on the mental wellbeing of employees without any risk of criticism of sacrificing productivity.

But Am I Doing the Press-Ups?

I'm fortunate that I've never experienced a mental health problem, and yes despite what I've said above I do consider the primary reason for this to be luck.

As with physical illness many of the conditions that affect people will be completely outside of their control and only professional expert care and support over time can begin to help. There are steps that we can take to promote mental wellbeing. I wouldn't expect these to prevent serious conditions just as regular exercise won't protect from breast cancer or road traffic accidents, but everything we can do to promote awareness and understanding is a step in the right direction.

Given the state of my Facebook activity I was never going to raise awareness of PTSD, anxiety and depression by posting 25 videos of me doing press-ups but hopefully writing about it may have more impact. And yes, I will also be doing the press-ups (I'm 8 days in so far with 17 to go). Whatever form you find easiest to raise awareness of mental health issues, now is as good a time as any to do so.

References and Further Reading

The ACAS website provides free advice in the UK for employers - https://www.acas.org.uk/supporting-mental-health-workplace
A useful summary of positive psychology interventions and depression - https://positivepsychology.com/positive-psychology-depression/
Some figures and references for the US can be found here https://www.mentalhealthfirstaid.org/2019/02/5-surprising-mental-health-statistics/
I can strongly recommend reading the Happiness Advantage for any leaders who want to justify promoting a happy team culture - https://www.shawnachor.com/the-books/the-happiness-advantage/

Image by alex-mccarthy on Unsplash

The one question you should be asking about remote working

2020-04-30T23:00:00.000+01:00

This post is about the most important question you should be asking about remote working.

This is not a post to answer your questions on remote working, but I'm hoping it may cause you to ask some.

A lot of people are questioning the best ways to do effective remote working, this is not a post about that.

Some are questioning whether remote working could be the new normal, this isn't about that either.

To find out what the most important question is about remote working, I'll start with a question myself.

If the move to remote working of your software team is presenting significant challenges to the leadership of that team, what does this say about how healthy your culture was in the first place?

Why co-location works

I'll be honest at this point and say I've always preferred having a primarily co-located team for a number of reasons. In my teams in the past I've always looked for people who are able to access the common place of work as I feel it provides a number of benefits.

There's a huge amount of engagement and focus that comes from people in a shared space working together towards a common goal.
Co-location allows low friction, light touch leadership where team members can get quick pointers of guidance at opportune moments when they can see their mentors are at a natural break. Even with the most efficient on-line tools it's hard to know what someone is doing at the exact point you decide to interrupt.
There's a lot of value in being able to see body language and non-verbal signs of stress or frustration in colleagues that simply don't come across remotely.
There's a huge amount of productivity that comes from people overhearing conversations that are going on and chipping in if and when they can help. As I wrote in my post on bug "Feeding frenzies" - eavesdropping is one of the best techniques out there for picking up on problems, frustrations and opportunities or simply stepping in to correct mistaken assumptions.

Yup - when this is all over if I'm lucky enough to still be working I'll still prefer leading and working in a co-located rather than remote team. It may seem surprising therefore why I wouldn't consider moving to remote working to be a significant hurdle. The reason is simple - I believe that the characteristics of a team that provide for healthy remote working, are the same characteristics that provide for a healthy team in any context.

Trust shouldn't be a new thing

I can think of 3 key characteristics of working relationships which are essential to successful remote working - but this post isn't about successful remote working. The key takeaway here is that these are characteristics that believe are important in any team.

Trust - it isn't a new thing in this age of remote working. In co-located situations I still believe that a heavy dose of trust goes a long way in establishing a motivated and productive department. Allowing people to be flexible with their own time management has been a principle of mine for years and it always surprises me when I've employed people who found this approach to be a refreshing change from previous roles. In a fully remote context it's simply not possible to monitor what people are doing every hour, but if you were doing this in the office then that indicates a potential lack of trust that could be having a major impact on your team morale and engagement.
Autonomy - Having autonomy over your own work is another key element in employee engagement and motivation that is just as important in the office as in remote work. If providing people with autonomy over their work is a new and strange idea in the Covid-19 world then perhaps that's something to think about when you get back to the office, because if you're micro-managing them with piecemeal task allocation this could well be preventing them from truly engaging with their work.
Flexibility - people have lives outside work. Despite the best efforts of some Silicon Valley companies to get employees to live, sleep and breathe 'the company' - healthy and happy employees are ones with a work-life balance where their home life is their own - and that means flexibility. Flexibility can be harder in an office context but giving folks the keys and allowing them to come and go flexibly can remove a huge amount of stress for people, whether it's allowing them to do the school run, missing the rush hour or working from home at key times.

Put simply - I believe that these should be characteristics of any healthy software development team, whether remote or not. Building an effective team culture in an office context should implicitly prepare you for working remotely and if you're having to rethink your levels of trust, autonomy and flexibility in the new remote world then I suggest your office culture was overdue a rethink anyway.

The servant office?

I'm sure that some in the light of current events will be discussing whether an office is necessary at all. It's an interesting idea, but for me the more interesting questions is - what was the office for in the first place?

For those with a more command-and-control management approach an office can provide a mechanism for monitoring the activity of individuals. Ensuring people physically come to work gives a level of control over time spent working, activities performed and even clothes worn whilst there.

As anyone who has read "The sacrifices of the servant leader" will know that I align more closely with the idea of servant leadership where leaders are there not to control and assign tasks but to serve teams, clarify goals and remove blocks. Adopting a similar view to our physical working spaces provides a compelling insight of the purpose of the modern office.

Once we establish trust, autonomy and flexibility into our teams then an office is no longer a place for managers to control work. Instead the purpose of a shared workspace is to provide a hub where empowered team members can come to get support from others in order to do their jobs effectively. This support can come in many forms such as

from ongoing regular interaction with a team unit
through looser interactions sharing support and information with other stakeholders
from leaders who are there to provide guidance and remove blocks
from coaches and mentors who can more effectively provide guidance and advice face-to-face

Looking at an office in this way, what becomes clear is that while there's benefit in having overlap in presence between those who need and provide that support, in reality as long as people get the benefits that come with co-location they should come and go as they please.

It's not about remote working, it's about agility

So what is the most important question about remote working? After all there are already many posts out there looking to answer the questions that some may be asking right now - "how do we effectively work remotely", "how do we organise virtual teams?", "how do I run remote meetings?".

I think that the most important question you should be asking is

"So what?"

as in

"yes my company has moved to remote working - so what?"

I can honestly say I've not felt the need to look at a single post or attend a single event on effective remote working since this all began. The reason for this is that I work in an organisation with a high level of agility built around trust, a huge amount of autonomy and hopefully working relationships that provide support that allow people to perform effective work even from afar.

For organisations that find the transition to remote working particularly challenging as they fear they are losing control and aren't sure what people are doing - this may say more about their culture than it does about having to remote work. If the current situation highlights anything it's not the importance of learning how to shift to remote working, but the cultural importance of this not being a shift at all.

Footnote - clearly this post is aimed at software teams finding themselves remote working as a result of global lockdown. I appreciate for many this situation hasn't just brought a situation of having to work remotely, but many far more serious consequences both in employment and health, for those more seriously affected I wish you all the best and hope that you are able to return to a situation where you have to worry about such trivial things as remote working very soon.

Photo by Jules Bss on Unsplash

Using Outcome Based Documentation for Scoping Agile Developments

2020-02-16T23:17:00.000+00:00

Have you ever been asked to create scoping documentation for an agile development? It's not easy is it? You've probably found that, amongst the many benefits of focussing on customer collaboration over contract negotiation, there are also challenges. The worlds of agile and formal software purchasing don't make for happy bedfellows.

Agile teams have embraced doing as little documentation as they can to support their development processes and avoiding contract negotiation is actually enshrined in the manifesto.
Companies purchasing software or development, on the other hand, rely on documents such as specifications and scopes of work to ensure that they are going to achieve the benefits they expect for their budget.

The last thing a customer wants to agree to is buying development sprints on a 'time and materials' basis to see what you come up with, even though in an ideal world that's what you'd want to sell to allow for flexibility and limit your risk. If this sounds familiar - I have good news! Creating flexible but powerful scoping documentation to bridge the gap here is possible - and in this post I'll show one way of doing this.

Some approaches that don't really work

A few years ago I was working for a company that was struggling with client development projects running over at high cost to the business. If we look at their purchasing process it's understandable why. The contract negotiation was run by account teams using beautiful agency produced designs to impress the client. The design process gave no consideration to user experience or practical ability to deliver and so inevitably the development overran with a lot of time sunk into achieving the exact design rather than adding value. In one extreme example a team spent over two weeks getting a smiley icon to change on a mobile slider control as it was moved, even though the users finger would be obscuring the icon during this process - it was in the design so had to be included.

More recently I've had a similar need, though this time the approach being used focused on tightly scoping the technical details involved in the delivery. This was better and provided much more confidence in the ability to actually deliver, but did come at the expense of a clear focus on the user and their goals. The result was an integration that worked from a technical perspective but left the end user with too many manual steps to achieve their tasks, and the customer ultimately a little disappointed.

Focus on outcomes

Despite the different approaches, the challenge in these situations was the same. How to produce documentation that:

Was robust enough to get it through a contract negotiation or purchasing team
Provided clarity for both parties on what we were aiming for and a basis for confirming when we were done
Allowed for flexibility in how to deliver, allowing for undiscovered technical constraints

For me the answer lay in the mantra of high performing teams everywhere

Focus on outcomes not outputs

i.e. focus on what the software will allow people to achieve, rather than on the delivery of the software itself.

(A common example to support this way of thinking is that people don't want a 1/4 inch drill they want a 1/4 inch hole. I personally I find this strange. The last time I used a drill the last thing I wanted was a hole in my wall. I did, however, require somewhere to store my cookery books and a shelf seemed a good option.)

When selling software projects the important thing for the customer is not what is going be technically delivered, but what that will allow their users to achieve. Understanding and capturing that information is key to providing a flexible yet robust scope of work.

Capturing the outcomes

The format that works for me is to structure a lightweight scoping document to allow a clear focus in the body of the document on the outcomes desired, pushing technical constraints and limitations out to maintain readability. For the outcomes I break these down into three parts

A high level outcome statement
A few success criteria
Any assumptions

Let's look at these in more detail

High level outcomes

I like to present a number of high level outcome statements. Each outcome needs to be carefully considered as we're aiming for as few as we can get away with here. Each also needs to be targeted at a specific role or stakeholder.

Some examples

Allow an agent to send a message to a list of contacts
Allow an tradesman to register a device installation
A manager can approve a draft design from one of their team
A marketer wants to personalise a message using contact data
The system owner will be able to see their account usage

I've intentionally mixed the format here as I don't think it's necessary to insist on one structure, and while consistency within any one document is important, insisting on formats like 'As a...I want...so that ' with customers is frankly annoying.

What is important is conveying a desired outcome that has clear value for an identifiable role.

List success criteria for that outcome

Just as when elaborating user stories for ongoing development adding acceptance criteria is essential, Including success criteria in outcome based documentation is key to ensuring that you and the customer are on the same page. The criteria should be statements that provide more explanation in terms of what an acceptable outcome will look like

It shouldn't be necessary for the user to do any configuration in other products in order to send a message
The marketer won't be able to send more messages than they have credit for in their account
The tradesman will be able to complete the process on a mobile device in a potentially dark and dirty work environment

The key here is in identifying criteria that will allow the target users to achieve the outcome they want, in a way that works for them. If the user has to step outside of a natural workflow for them in order to use the software then that isn't a positive outcome - so whether it's being able to use the product on your phone, outdoors in high wind, with dirty plumbers thumbs or through surgeon's gloves - these criteria are the key to ensuring the outcomes are delivered successfully.

List any assumptions to the ability to deliver that outcome

When working with a level of uncertainty we need to make assumptions in order to progress. These could be based on the need for supporting data or capabilities outside of our control, for example

The 3rd party technology used will provide reporting data on individual message delivery
The data from the customer training system will provide a suitable ongoing reference list of users in the system.

These assumptions can be invaluable. I've seen project priorities shift massively due to data on the customer side that was assumed by the them to be reliable but was actually unusable. Appreciating that these are assumptions and presenting them as items to be investigated and confirmed as part of the process makes it much easier to discuss the impact should they prove to be false.

Other bits

As well as the outcomes there are other elements that make up a good outcome based scoping document. I find that a structure like this works well:

Introduction - as well as defining what the project is for its useful to clarify the characteristics of the approach being taken, particularly the acceptance of uncertainty and how this could affect delivery.
Outcomes - the outcomes as I've detailed above including success criteria and assumptions
Technical considerations - details around the technical operating environment that need to be considered such as security expectations, target browser levels and devices and hosting.
Appendices - here I push any detailed items that would impact the clarity of the outcomes, such as data source field listings and reference tables. If it's necessary detail but would make the desired outcomes less clear if included there, it goes in an appendix. I've occasionally also included details in here that need to be completed to provide a clearer scope, such as information on the key fields with which users will be uniquely identified.

What about timescales and planning?

If you are planning to sell a development with an agile approach then some flexibility around delivery is needed. This is a difficult negotiation as the customers much prefer fixed cost and scope projects where the supplier takes on the risks. An effective approach I've used here is to define fixed size delivery 'buckets' or phases. Initially each phase will have assigned essential outcomes, but also some flexible ones that may be delivered, or may be rolled into the next phase. The process outlined at the outset included re-prioritisation in each phase to give the customer control over whether to continue based on the original priorities, or shift to emergent ones.

Will it work for me?

If you're more used to working with fixed specifications you may be doubting at this point whether an outcome based scoping approach would work for you. You'd be surprised. Most organisations are now using agile methods or will at least have some kind of transition project in place, so finding in-house support could be easier than you expect. I've successfully used this approach in some robust purchasing processes in for large development projects in both the UK and US and was pleasantly surprised at the positive reaction.

The fact is that when establishing outcomes what you're creating is a document that places an understanding of their users and their needs as the focus for the entire process, rather than a flashy design or the details of the technical delivery. And if you think about it that way - I think you'd be hard pushed to find customers who wouldn't want that.

References

There are literally hundreds of articles out there on outcomes over outputs - here's one, Google will find you a whole load more.

https://hbr.org/2017/02/you-need-to-manage-digital-projects-for-outcomes-not-outputs

Why we need to get rid of thought leaders

2020-01-26T22:24:00.000+00:00

In the busy world of software blogging and speaking circles it's tempting to use an attention-grabbing, controversial title to present an often less than controversial subject. One method that's particularly effective at getting attention, primarily because it stirs up strong emotions, is the post title announcing the death of a software role.

This happened with testing a decade ago as people proclaimed that 'testing is dead' (most famously a GTAC keynote by Alberto Savoia), while actually discussing an evolution of testing skills and responsibilities. More recently I've read some similar arguments in relation to product owners, tempting us with inflammatory statements around 'doing away with Product Owners'.

I understand the reason for this kind of positioning. Challenging the status quo is a proven technique to drive readership and maintain a position as a thought leader. At the same time I think that there are real dangers to this kind of positioning.

The title vs the content

Here are two articles that have been shared with me recently. Both nominally about getting rid of product owner roles.

Mike Cohn's article "Is it time to do away with Product Owners"
and Joshua Kerievsky's "Eliminating the Product Owner"

On the face of it both appear to suggest that the Product Owner role is no longer necessary and should be removed. To support this both authors do argue that it should be a whole team approach to understand stakeholders and maximise value for them, this shouldn't be the responsibility of just one role.

Reading more deeply though - what both authors also suggest is that teams taking on this responsibility should include an individual who specialises in product thinking, just as other individuals take more responsibility for, say, testing (who obviously aren't testers, that role is dead). This is a far less dramatic shift than suggested in the post titles to the extent that the cynic in me feels that a more appropriate title for such a post might be:

'Is it time to subtly change the product owner role to be more embedded within product teams and to collaborate more with those teams to gain consensus on prioritisation decisions?'

however that would be a far less controversial position, not least because that is what most of the good product people I've seen were doing anyway.

Where's the harm in getting a bit of attention?

So one might argue that there's no harm in presenting a non extreme argument under a more controversial heading to get a bit of attention. I disagree. I personally believe that such positioning does cause problems. If politics has taught us anything recently it's that simple punchy and memorable messages persist faster and further into common consciousness than the boring practical details. What I've observed is that people can make some extreme decisions using 'current thinking' as justification.

By way of an example - a few years ago I worked with a company who had taken the 'testing is dead' position literally and had taken the approach of having no testing expertise in the building. They'd left all of the testing responsibility to the developers, without providing those people with any training in testing skills or establishing a clear definition of responsibilities. Needless to say they were struggling with reliably delivering working software and were suffering from high impact of production issues.

Stripping out roles and relying on 'the team' picking up new responsibilities without the requisite expertise is not something that any team should consider lightly. Read deeper into any post proclaiming the death of a role and you'll discover a caveat of keeping the skills provided by the individuals in that role through some other means.

Why not to get rid of product owners?

Just in case anyone was considering taking a literal response to posts like the ones above and performing a blanket cull of product expertise in your teams, let's look at the potential consequences. I think it's worth exploring some of the challenging situations that I've encountered when a clear product role is missing and prioritisation responsibility is left to the developers in the team.

Persisting siloed working

Not all teams operate as a cohesive unit. Some teams operate entirely as a set of distinct individuals who are all working in parallel on different things. Each person in the team can be picking up their own tickets with little consideration for what the others are working on. A product role done well will really bring a disparate team together by focusing development efforts around common themes and goals. Not only does this encourage collaboration but it also helps to other roles such as testers to focus their efforts.

Missing out on economies of focus

The product owner isn't just there to prioritise individual tickets, but also to synchronise related work. A huge amount of friction and expense comes from developers having to re-acquaint themselves with the code behind a feature when picking it up to work on. The process of consolidating related work into themes around product areas can result in dramatic savings in the overall time and effort of maintenance through minimising context switching. Collating and coordinating this work takes a considerable effort, but the absence of this effort results in more piecemeal and high friction work.

Not picking things up in priority order

Another behaviour I've seen emerge when prioritisation is left as a team responsibility is a tendency to skip down the priority list to avoid the tricky or lengthy tickets. Unless a team has really strong discipline then some members can fall into the habit of cherry picking from the backlog until they find something that appeals to them. In one extreme case I saw a team bypass clearly important negotiated customer work in the backlog to address other items that they preferred, leaving the company in a challenging position to explain why the paid work had been deprioritised.

Not considering the bigger picture

One of the responsibilities of the product owner is to ensure that they understand the business goals and align the work to maximise the chances of achieving them. In addition to meeting existing user needs this will also include considerations such as increasing revenue opportunities from existing customers, or supporting sales and marketing efforts. Without someone taking the responsibility to keep appraised of these needs, a prioritisation bias can emerge towards short term problem solving at the expense of strategic progress.

It needs a great team

Given the challenges I've presented here you may assume that I'm against team prioritisation, however this isn't the case. One of the best teams I ever worked on didn't have a specific product role and prioritised effectively based on a top level technical roadmap defined by the CTO. What allowed us to do that was a strong team built around multiple capable leaders with strong mutual respect. I've seen plenty of teams that don't have such a strong foundation for whom a product owner role was hugely beneficial.

I believe that it is important to consider the opinions of the whole team in prioritisation decisions, but that specific product expertise plays a critical part in informing those decisions. This doesn't necessarily need a devoted Product Owner in each team, but it does require someone with an understanding of the demands on that team and the implications of not doing things. What I'm aiming to highlight here is that if a team is not working well, a knee jerk response to a "Get rid of Product owners" message could well make things worse by leaving prioritisation decisions to the mercy of the most opinionated technical members.

Getting rid of thought leaders

Hopefully by this point the sarcasm in the title of this post is apparent. I don't think we should get rid of thought leaders, just as I don't believe we should 'get rid of' Product Owners or Testers. What I do believe is that all roles have to evolve - but successful evolution depends not on losing skills but on the people in those roles continously learning and advancing their craft.

Testers needed to evolve away from after the fact script running and embrace shifting both left and right in providing more ongoing feedback right from problem definition through development and into production use.
Product roles need to act less as remote indisputable decision makers and embrace gathering and supplying evidence to teams as influencers and information providers to help build consensus around how best to advance their products.

And maybe thought leaders need to appreciate that: what works in one context doesn't necessarily provide a blueprint for all others; a team evolving how they deploy and use specific expertise really doesn't justify announcing the death of that role for an entire industry; and ultimately that headline messaging should be respected as it propagates faster and further than the detail inevitably will.

Photo by Gary Chan on Unsplash

How to write great acceptance criteria

2019-12-10T03:01:00.000+00:00

Documentation is like alcohol in that the more we distil it down, the more powerful but potentially hazardous it becomes.

I'm a strong believer in minimising documentation. I'm also well aware that as we reduce the information we capture, the importance of what's left relatively increases. Nothing supports this more than acceptance criteria that are added to user stories.

I personally believe collectively elaborating user stories to identify acceptance criteria to be the most important team activity in agile work, even more so than retrospectives. I therefore find it surprising how some people under-appreciate the importance of creating acceptance criteria. On many agile teams I've started working with writing 'ACs' has either not been done at all, or if it is done is something the Product Owner is expected to write in full well before the story is started (I challenge that approach here). In this short post I'm going to focus specifically on what good acceptance criteria look like to me.

What do good acceptance criteria look like?

With great power comes great responsibility. By their very nature user stories should not dictate how value is delivered, but an effective elaboration process should identify options that need clarification. Well written acceptance criteria will capture the points of ambiguity that come up in our user story discussions and remove this in a clear and simple manner.

They are focused on user outcomes not outputs

For me the most important characteristic of good acceptance criteria for me is that they are written with the aim of delivering an outcome for the target user, rather than an output of the development team. Most user stories will have a one line value statement (maybe in a format like 'as a... I want... so that...' If you insist on that kind of arbitrary rigidity). Instead of clarifying a solution the purpose of acceptance criteria is to expand on this to more explicitly scope the problem being addressed. The reason this is so important is that it maintains a focus on the user and the value they want to get from the change which is vital for effective critical assessment of the solution.

They allow for changes in approach

A good acid test of whether we've achieved the above is it the acceptance criteria are resilient to a change in technical solution. I've seen teams that have embarked on a development only to discover that their first attempt at a solution proves to be unworkable. A well written set of problem focused acceptance criteria will allow for a rethink on the approach to a solution without any need for a rewrite the criteria supporting it.

They provide just enough points to scope

One of the key tenets of an agile approach is to keep things lightweight and avoid excessive documentation. The last thing we therefore want to do is burden the process with a lot of documentation at the last minute. The key here is capturing a bullet list of just enough points to be confident that we're progressing with a shared understanding. I typically aim for 3 to 8 points, more than this and I'd be looking at whether it was possible to split an item down.

They consider all affected stakeholders

The headline of a user story will hopefully focus on providing value to a primary stakeholder. Even the thinnest slices of capability have impact on other roles and it is important to represent their needs. In addition to the target users, any roles that shouldn't be able to access a feature need to be identified. Also administration and support users need to be considered in terms of the events they need to respond to and the information they need to do so effectively. Identifying the other users impacted and the outcomes for them is an important consideration for a robust solution

They consider negative as well as positive scenarios

A user story title will typically only cover the positive outcome we're looking for. Acceptance criteria should go beyond this to capture what we expect to happen in negative scenarios too. What do we expect to happen if the user doesn't supply the prerequisites to complete a task? What subsequent decisions to we need to support if this happens? Who will be informed of a batch failure and what they need to be able to do with that information? Considering the potential negative cases is vital to establishing a robust solution that avoids an overwhelming workload for your support team.

What about other stuff?

Not everything needs to be baked into our acceptance criteria. Sometimes points come up out of discussions that simply don't make sense to add to the success criteria for a story. I typically look to capture two additional types of information that cover most needs and help to guide later development and testing.

Working assumptions that help to scope the problem.

I encourage teams to identify any assumptions that are needed in the absence of knowledge to provide a starting point in framing the problem. This can include vital things like clarifying when we're deferring certain responsibilities to later work in order to reduce the scope. It's also useful to present figures that can set an expectation of reasonable performance while avoiding baking these into as fixed acceptance criteria (e.g. the page must load in under 1.5s) which can lead to a lot of wasted effort pursuing arbitrary goals.

Development risks

As an ongoing process it's important to capture the risks we perceive to be inherent in our approach. This may be to guide the developer to factor in some mitigation into the solution, or the tester to ensure they focus on the risk area, or both. What we want to ensure is that if we identify risks that simply aren't naturally covered by problem focussed acceptance criteria, then these are still captured in a way that allows them to be acted on.

Is it necessary?

You might argue that capturing acceptance criteria (and risks and assumptions) is still favouring documentation over face to face communication. I disagree. Just as a shopping list helps to ensure we don't forget the things we knew we needed when we left the house once we are in the shop, the acceptance criteria are simply there as a reminder of what we decided we needed to cover through our face to face discussions. In order to do this though they need to convey the same intention outside of the context of that conversation, and will only do so if written well. Given the scope for confusion if we don't have our high level outcomes captured, I don't believe that taking a few minutes to agree, capture and share a handful of key points is a high price to pay for a clear testable definition of success.

Photo by Adam Wilson on Unsplash

Your overwhelming product backlog is actually two

2019-11-17T23:11:00.001+00:00

Facing an overwhelming backlog is a challenge that anyone in product roles or agile teams will face at some point in their career. It was a common enough challenge to be the subject of an entire discussion at a meet-up I went to recently. Many folks there, myself included, had joined companies or teams as product managers only to inherit enormous existing backlogs containing potentially years of development work. If you've been in this situation you'll know that it's a struggle to manage the expectations of too many stakeholders, each of whom wanting you to prioritise their particular items at the expense of others.

I believe that a large part of the problem is when we view as one backlog, something that is far better viewed as two...

Easy to grow, hard to deliver

Sometimes practices are adopted by teams because they are the right approach for the context that the team is operating in. At other times we do things simply because everyone does it, rather than through a clear understanding of what we're trying to achieve. Product backlogs can suffer from this problem - they're an assumed part of modern development and it's all too easy to fall into the trap of growing a significant backlog without knowing exactly what you're going to do with the items in it.

Adding something to the backlog provides a short term fix for the product manager to ease pressure from stakeholders.
Having something added is perceived by those stakeholders as the first step to getting it delivered
Items are rarely if ever removed to avoid upsetting anyone
The backlog grows to be so unwieldy that overlap and duplication between items is commonplace
The vast majority of the backlog remains perpetually undelivered. Instead what happens is that items are added to and delivered from the top of the list. A small and fluid layer of items flows in and out of the list while the remainder stagnates into an irrelevant morass.

This situation isn't just frustrating - it can impact you commercially. A few years ago I worked on a project to create a new loyalty programme for a large corporate client based on a successful programme for a sister brand (that was on too weak a tech stack to reuse). At the point I was asked to take it on the account team had agreed that literally every feature from the existing programme would be recreated. This was a system that had evolved over years, with some of the features suffering very low or zero use. Even delivering the core, high value capabilities was a huge task. Once that was achieved both the customer and we found that we were prioritising other higher value items over the ones in the backlog. This should have put us in a really strong position to be shown to be delivering a high value capability in an agile way, but instead the weight of existing backlog meant we were always in a weak negotiating position.

What I see as the root of the issue with situations like this is that a single approach is being used for two very different needs, and the first step in tackling an overwhelming backlog is to recognise what these are.

Need 1 - Tracking items through development

The first purpose of a backlog is to track items through development. In my experience it helps to keep this as short as possible - to serve its purpose it's only necessary to include things here that are committed for imminent development.

Keeping this list to only the items that are in scope for research or development work is essential to maintain a focus on what the team are working on and I typically just maintain the items pertinent to the current release period (e.g. quarter year) in this list. It also helps to take the pressure off the PO or PM to be constantly curating a massive list of items and track which ones are ready for development. It's far less effort to keep a tidy window box than maintain a landscape garden.

Need 2 - The ideas list

The second list has a completely different purpose which is to capture potential future developments. It's a place for capturing feedback, insights and ideas on what might be valuable to add to the software in the future. In this list we want to connect related feedback together to allow an informed comparison to prioritise against other potential developments. Any information that helps to understand the value of the item, including the evidence to support our confidence in the value of the item and any information on feasibility and effort.

What we're not trying to do here is prep things for development. If we accept the fact that there will be a decision point on progressing something into the development backlog then we can be much freer in how information is captured in this list. It's fine to reference notes, early sketches, photos of whiteboards as well as customer quotes on their needs without worrying that these may inadvertently picked up and translated literally into product features.

When adding items to the ideas list I make it clear that these contribute to prioritisation of future work but there's no certainty that they will get developed. This message needs to persist right out to all roles that communicate to customers, so that they don't give the impression that accepting a 'feature request' means anything other than extra information to help in prioritisation.

How to do it

Once we appreciate the fundamental differences between our lists then it becomes clearer that we need to manage these in different ways. For tracking development having a physical display in the room during discussions, on either a physical board or on a TV, is important to give visibility and allow collaboration between roles. For capturing feature requests and ideas the need for collating different sources of feedback and data to feed prioritisation decisions requires very different capabilities more focussed on cross-referencing, indexing and ranking.

I've used a few approaches to managing these separate concerns.

Jira has a really flexible organisational structure around boards and custom types. When working with Jira an approach I have used one board to gather 'ideas' as a custom ticket type, and then translate these into Epics when I want to commit them to the development team backlog.
Microsoft Azure Devops (formerly TFS) has a hierarchical structure of teams, areas and iterations. I have managed longer term activities using a Product 'team' looking at a top level iteration based on epic items, pushing more detailed items into development teams based on more granular iterations when they are committed for development.
The best way I've found, however, is simply to use two different products, one designed for taking development work and one specifically created for capturing roadmap items and gathering feedback requests. I currently use ProductBoard for capturing customer insights and planning strategic roadmap, with Azure Devops used to track work through the teams. The tool has a nice capability of capturing customer 'insights' via email or from our support system and linking these to potential features (I have no connection to this tool and don't recommend it over others serving a similar need).

I typically don't capture supporting research and high levels of detail in a tracking tool. I prefer to persist detailed research in a wiki and add links to the relevant items, as wikis are easier to organise and find related information that can apply to multiple potential developments.

Names are important

Splitting a backlog isn't just a way to improve organisation. Changing the way that you communicate around feature requests is an important first step to taking ownership of the product direction. When ideas or feedback are captured into a 'backlog', that carries an implication - the name backlog means 'an accumulation of uncompleted work'. This is an unfortunate terminology that implies development teams are permanently lagging behind where they should be because in an ideal world every item should have been delivered already. Any list of potential developments and feature requests is not a product 'backlog' because the future is uncertain and just listing ideas should lead to an assumption that they will get done.

While we're on the subject a huge list of desired capabilities is not a 'roadmap' either. The very existence of a large backlog that a product team is expected to deliver inhibits strategic planning so much that it would more accurately be described as an 'anti-roadmap'. What it is is a catalogue of potential opportunities, and the Product role should be focused on selecting from these in a way that provide the greatest value, irrespective of whether they've were identified years ago or yesterday.

So if you are in the situation where you are struggling with an overwhelming backlog, the approach that I would recommend is

Create a second 'ideas list'
Move anything not committed for imminent development into it
Establish some clear rules around accepting feature requests
Communicate the basis that you will prioritise items into development

Then hopefully you'll be able to stop worrying about how to get through your enormous backlog, and start being optimistic about the great list of opportunities you have to improve your product.

Photo by Achim Pock on Unsplash

Too Many Conversations?

2019-10-24T20:53:00.000+01:00

I was at a daily stand-up not long ago and a developer gave an update that went something like this

"Yesterday I was mostly in meetings so I didn't get a lot of work done, I did find some time to fix a bug and do a code review."

thereby expressing a very clear opinion on what real 'work' was to them - and time spent in meetings clearly was not it.

This wasn't an isolated event. I heard similar updates from the same developer many times, and I've worked with others who also expressed similar views. The sad thing here is that all it took to achieve the label of 'meeting' in this person's eyes was the presence of more than one person discussing a work related topic, or as I like to call it, a conversation.

When Meetings go Bad

Let me say right from the start that I believe a heavy meeting culture is a pain and impacts productivity. Long, regular meetings involving lots of people are an expensive business and can dominate the calendars of middle and senior managers if not kept in check. The perils of the meeting culture are well covered elsewhere (and I'll include some links in the references at the end of this post as to the best pieces I've read on the subject), so I'll stick here to summarising the three main issues I see with a meeting culture:

Too many people involved. It's simply unnecessary, and expensive, to have everybody in every meeting. 8 people in a 1 hour meeting is a whole day of work. If the output wasn't worth giving over an entire working day to, then there were too many people in the meeting.
Too long. Another challenge is allowing far too long for meetings that don't merit the time. Parkinson's Law relates to the fact that work expands to fill the time available, and rarely do I see this more apparent than in a 1 hour scheduled meeting.
Too frequent. If a meeting is regularly scheduled and you're not making valuable decisions each time you sit, the meeting probably doesn't need to be on repeat. Those of us in roles that interact with a lot of teams and departments find that their calendar is easily swamped when regularly scheduled meetings are a standard activity in a business.

I've been personally guilty of falling into these traps on occasion, though I find that an awareness of the problem is the first step to avoiding it. What bothers me is that the 'meetings' the individual at the start of this post was referring to were nothing like what I've described here.

Conversations aren't meetings

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Despite being explicit in the 12 principles of the agile manifesto, I find that this principle is one that is most heavily resisted by some individuals. Some still persist with the opinion that unless you're coding you're not doing valuable work. It's frustrating how people that are otherwise enthusiastic about agile principles would so strongly reject one aspect that is so fundamental to them.

It's unsurprising that the group that I've seen this most commonly is software developers. I reject the stereotype that developers are an antisocial bunch, but I do believe there are some pervasive practices that promote the idea that the only valuable work is coding:

Some of our mechanisms to measure development 'productivity' specifically promote at-desk coding as the sole measure of progress - yes "source lines of code" I'm primarily thinking you, however agile sprint velocity and kanban status columns can also be abused to the point of promoting the completion of tasks over the successful delivery of value.
Our hiring processes similarly focus predominantly on the purely technical. I've yet to see a developer hiring process that required a developer to actually speak to someone to establish the nuances and assumptions of a user problem before undertaking the obligatory coding challenge. More often we place a technical coding problem in front of them and rely on discussion with other deeply technical roles as the only means of assessing softer skills.
Having discussions raises criticisms and questions that take time to resolve. It's much quicker to reach a solution based on how you see it working and defer critical feedback to the end than it is to have your thinking challenged up front. Discussions amongst stakeholders often expose the nasty, real-world complexities that undermine our nice elegant solution models and feel like they are slowing development progress (even though this kind of activity actually vastly reduces the effort needed during testing and review). It's hardly surprising then that some folks prefer to avoid them.

With these factors driving the perspective that conversation takes away from productive work, how can we promote the need for healthy interaction to support productive development?

Rephrase the problem

There are practical ways to reduce the negative perception of meetings. Where they are needed try to encourage sessions that

Focus on a specific decision and just long enough to make that decision. I find it useful to focus on coming together to agree direction and identify next steps rather than trying to solve all the problems at hand in one long meeting.
Are arranged as near to the time needed as possible. Try to organise at just the right moment to prevent blocks whilst not being so ad-hoc as to impose interruptions - people need time to plan their quiet work. If you have a daily standup (is anyone brave enough not to?!) then this is an ideal time to discuss and arrange appropriate times for any conversations needed.
Involve only the relevant people. Have enough people in the conversation to avoid excluding people affected, but no more. In other words - invite the testers.

Keeping discussions lightweight, on-demand and just-long-enough will certainly help to avoid becoming an organisation that is paralysed by meeting culture. Sadly, as I've discovered, it won't remove the challenge of the 'we have too many meetings' argument. This is a problem that needs to be addressed at the cultural as well as the practical level.

Instead of referring to 'meetings' try talking about 'conversations' or 'catch ups'.

"Yesterday I had a conversation with the CTO around to decide how we were going to progress the security rollout, and a really useful catch up with Andy and Sarah to decide the final tasks needed to complete their active story."

This isn't just idle semantics. The word "meeting" conjures up images of a formal event, with pre-defined parameters that is scheduled to fill an allotted time slot. Sometimes this formality is required but often it's overkill for the needs of software development teams. We tend to use the term 'catch-up' in my company to imply a short, single-point agenda conversation with minimal attendees organised at the appropriate moment to make a decision. These catch ups are requested and scheduled at or just after stand-up so people can loosely plan them in on the day when they are needed. Often a catch up involves only two people, but each of those people has committed to the time to tackle the decision at hand. This commitment is key - someone wandering over to your desk or calling on Skype is an extremely effective low friction way of having discussions, but in such a situation it's perfectly acceptable culturally to terminate the conversation suddenly for other commitments, like being overdue your 11am coffee, or hearing the sandwich van arrive. What we're aiming for is the lowest friction, minimal impact conversation that is scheduled enough to prepare for and plan other tasks around.

Look at who you're hiring

When using agile methods it's critical to have people that respect the value of conversation in decision making, and enjoy collaborating with their colleagues to deliver value. If your team contains people who prefer to stay at their desks building poor software based on false assumptions, then you need to look at who you are hiring.

I'm always open to being challenged, and when there has been valid argument in the 'too many meetings' criticisms I've taken it on board. Instead what I've seen recently was that the individuals most critical of time spent in conversations, were also the ones whose work most frequently missed the mark. They were the ones whose solutions just weren't thought through. At best this involved having spend far more time in reworking and reviewing that was necessary, at worst it involved having to simply ditch the changes and start over. Conversation is essential in the process of having your work held to account, and avoiding scrutiny through the 'too many meetings' argument is disingenuous. The simple fact is that you can't avoid scrutiny for ever and the later you leave it, the harder it hits.

References

A couple of the better posts I've seen critiquing a meeting culture

HBR Stop the meeting madness https://hbr.org/2017/07/stop-the-meeting-madness
Hackernoon - A good critique of meeting culture https://hackernoon.com/meetings-a-culture-of-excess-that-hurts-our-productivity-and-morale-464a5797c799

Photo by Headway on Unsplash

Agile State Modelling

2019-08-11T23:21:00.000+01:00

I, along with many others who adopt an agile approach to their work, lean towards a mindset that there's no 'best practice' in implementing tools and processes - but rather the right one to use at the right time. For me, processes and techniques, such as use of analytical models, are like tools in a toolbox. They are ready to be brought out at the appropriate occasion by an expert craftsman, or alternatively, me. Some are like a screwdriver, providing value in a huge variety of jobs. Others are like that weird special basin wrench that you bought to replace the tap (faucet) in the bathroom, less frequently useful but no less valuable for that when the right situation arises - like my leaky kitchen tap.

In the last year or two I've found myself increasingly finding the tactically applied state model to an invaluable addition to my tool set. I've always found simple state models to be a great testing tool but in a product management capacity a state model is also surprisingly useful as a method of communicating and reaching consensus across roles.

In early stages of development they are an effective way of collaboratively establishing a model for the problem space that can be used as the basis for the software solution
They provide testers an early opportunity to test flaws in solution thinking before these are encoded into software
They help to flush out inconsistencies between the thinking in different roles around how the software will map to the real world, and allow consensus to be reached around the scope and supported transitions within a feature.

All of these things and more make standalone state models a very useful tool, but it is actually in using state models in a more progressive, iterative fashion that I've found the greatest value in recent months.

Simple format

Let's clarify what I'm talking about when I refer to state model. There are different options for presenting state models right from very simple sketchy whiteboard styles, through to the rigid formal documentation kind such as UML state models (See here for a decent summary of the format).

Anyone familiar with this blog will guess that I lean towards the simple, flexible approaches that yield the most value with the least rigmarole. Lee Copeland's "Practitioners Guide to Software Test Design" provides an excellent introduction to a simple modelling approach that is probably the closest representation to the format I find useful.

When working with developers I typically operate a simple modelling representation of

Despite it's simplicity I've found this format sufficient to explore a problem space and flush out the flaws in early thinking on a solution. It also carries the benefit of being very easy to represent in Powerpoint - something that shouldn't be undervalued. Sometimes I stick to just using arrows to represent a transition, however I often find it easier to represent these as a shape simply because it can support multiple inputs and outputs for places where items undergo an equivalent transition. It also helps in discussing the models as it prompts the questions about whether certain states should support certain transitions e.g.

"Should we be able to delete from the edit page"

or whether certain transitions are equivalent e.g.

"Is deleting a published item equivalent to deleting a draft one?"

A worked example

Imagine we want to create a blog platform. We want to create new draft posts and publish them to read on our site. Before we dig into the problem in our optimistic 'this is a simple feature' naivety we might consider the initial model to look something like this

I can guarantee that after an extended user story elaboration session involving developers and testers, we're likely to have a less beautiful but much more representative model looking something like this.

This is one of the fantastic things about collaborative analysis - through the process of interactively modelling and questioning, we have collectively explored the problem domain. Together we have established a model for a solution that has addressed some flaws in our initial thinking that would certainly have surfaced later in development with greater impact. More importantly we have a model for a solution that is understood by all of the active stakeholders in the development.

Incremental States

The beauty of using a state model to support agile development is that it provides us with an elegant way of representing the incremental nature of the development, whilst ensuring that we have a robust solution at each stage. If we can identify a slice of our model to support at each stage of the development then we can develop and test a complete subset of capability. Developers can use the representation of each stage to be clear on scope , testers can to understand the incremental delivery and test the integrity of it, and product leaders can use to communicate progress and capability to a wider audience.

For example - in our first user story for our blog platform we may identify that we're going to support the ability to draft a post. We can identify a clean segment of our model that defines the scope of this piece.

The question comes up whether we want to support delete of drafts at this stage. We decide to include this as it provides a nice complete subset.

Now we want to deliver value quickly so we want to be able to publish our simple post.

We extend the model. This raises questions on scope

Do we need to cover reverting a published post to draft? (not yet that's a separate value item)
Do we need to be able to edit the published post? (not yet - let's focus on the top value item of publishing a post)
Do we allow delete of the published post? (No we will consider the workflow of published posts later)

We may still be missing some obvious capabilities, but we have established a valuable workflow with a clear solution state model that can be rigorously tested, without getting distracted in supporting other states and transitions which add less immediate value and can therefore be deferred.

And so on, incrementally as we build the capability and add items that provide further value, for example being able to edit a published post, where we may decide to allow save and publish of an unsaved new draft as well as unsaved changes in a published post.

and subsequently we may add a route to remove unwanted posts, whether published or not.

We have a way of clearly communicating the expectation of what states and transitions will be supported in each development step, as well as identifying where gaps are and ensuring that we have a complete model in place at each stage. We can apply a high level of rigour around what has been delivered as it should be a complete and coherent solution, albeit one that may not support all of the desired states of our final solution. This provides confidence in our ability to release ensuring we have no 'loose wiring' in the incremental stages of delivery.

Non-trivial examples

In many textbooks the examples given are so simplified as to be very challenging to apply to any real-world examples so it's worth me saying that the worked example here is very similar to a model that I drew up in an real session in the last few weeks (although I'll admit the one here hasn't had the benefit of collective elaboration and testing so could well have some holes).

As with many such approaches the value here lies less in the model itself and more in the value that comes from the process of creating it. Getting a team together at the start of an epic item and working through the creation of an initial state model can be a fantastic way of aligning minds on the bigger picture and how to robustly deliver value in stages.

I've found this approach to work best on greenfield developments that involve the introduction of completely new system entities with multiple states. It may be less useful when introducing other shapes of new capability. For example when adding a set of rich and complex interactions within a single component such as an image editor - other approaches will inevitably be more useful. Which brings me neatly back to my original point - now where did I leave that basin wrench?

Photo by Edouard TAMBA on Unsplash

Non-working groups

2019-07-04T22:24:00.000+01:00

Have you ever been involved in a working group? Or a guild, or tribe or any other kind of informal cross-functional special interest group? Yes me too. Lots of them.

And how many of those groups lasted more than 4 or 5 sessions? Thought so.

Did any of them pan out something like this...

Session 1:

"This was so great we should do this regularly, is monthly OK with everyone?"
Session 2 - One month later:

"This was so great. Who wants to run the next one?"
Session 3 - Six weeks later after a postponement:

"This was useful but - turnout is down - is monthly too often? Shall we do every other month? No-one's volunteered to run the next one but I've got an idea that might kind-of work so let's do that."
Session 4 - Three months later after rearranging 3 times and attempting to reignite interest in the work community social media site:

"OK so we had 3 people attend. Thanks for coming ... why don't we wait and schedule the next one when someone has a subject they want to cover?"
Session 5 - 6 months later with only the original two members now in attendance:

"I'm canceling the recurring meeting and shutting the group chat down as it's been dead for weeks."

...?

I'm guessing quite a few - I've certainly cancelled more than one monthly lunchtime outlook meeting myself. I don't think that it's necessarily right to view such situations as failures. In fact, sometimes I think the only failure is in thinking that every burst of collective enthusiasm to improve has to turn into a regular event.

A rush of excitement

I'm genuinely inspired by the energy that prompts the creation of informal improvement groups. People who are genuinely engaged with their work will always discuss the challenges they face. Their enthusiasm will seek out like-minded souls over water-coolers and coffee machines sharing ideas to improve. Before you know it a working group has emerged with great plans of regular meet-ups to change their working world for the better.

But the reality is that often the early enthusiasm wanes quickly and attendance can drop rapidly. I've been involved in setting up and driving so many groups and initiatives in all levels of my work that I can openly admit that those that have lasted are vastly outweighed by those that ran out of steam.

Why enthusiasm dwindles

Given the enthusiasm that abounds at the start of these endeavours, why is it that people with a common interest so often struggle to maintain levels of attendance needed to keep a regular meetup going?

Some of the reasons I've seen

Repeated conversations - the problem with groups created to address specific challenges within a workplace is that they are often borne of frustration with little scope outside of the group to elicit change. The attendees are brought together through common pain as much as common interest and the sessions quickly descend into the same rinse and repeat frustration based conversations.
Not enough topics - groups often arrange sessions around specific topics to provide focus and allow people to decide whether to attend. One challenge I've seen here is that often the originators of the group have a few 'hot topics' in mind when they set up the group. Once these have been covered off the well of inspiration quickly runs dry. (Its a bit like putting together a Playlist on Spotify only to realize that the 3 'similar' songs that inspired the list are the only ones that actually sound right for the list.)
Not enough hosts - this is probably the biggest challenge to maintaining any kind of meetup long term. Whether internal or more social, responsibility will inevitable end up falling to one person drive the ongoing sessions. Unless that one person is particularly strong at researching new topics or drumming up volunteers then the number of people willing to host a session quickly drops off.
Others are too busy - the biggest challenge to getting attendance from outside the organizers is conflict with other work. Expecting people to give up time for regular attendance to a group is only realistic if they get a lot out of coming to the group. Often once the sessions have moved on from the burning needs that initiated the group then the relative value drops to the point that, for most concerned, getting their work done becomes a higher priority.
The founder gets distracted - the people that set these things up are, by their nature, interested in tackling immediate problems and often once a group is up and running their attention will stray to other more pressing concerns. Only those with a strong candidate to take up the reins will last when this happens.
Too many groups - inevitably with and engaged culture there can be many interest groups and subjects competing for attention which will impact on people's ability to devote time to any one meet-up. People need to be selective with their time and will prioritise aggressively anything that is additional to their 'contracted' work.

Does this mean they failed?

It is a bit depressing when the inevitable outlook cancellation signals the end of another interest group. Does this mean that the group failed? I personally don't like to think in those terms.

Rather than considering that a group has failed, instead I'd ask the question of what made the attendees think that a regular group was needed in the first place. What I've seen is that the decision process to establish a regular meetup group is based purely on the fact that the founders have ideas for more than one session. It's an understandable but rather illogical decision that a few good ideas is enough for a regular meeting slot and in that decision lies the basis of failure of many such groups.

Tips for successful in-company groups

In my experience there are some ways to give groups a better chance of enjoying longevity. Some tips and ideas can help groups to stay the course

Start small and grow. I've found it's better to get a small number of hardcore people involved and coming regularly than trying to get half the company coming on a regular basis. One special interest group in test automation that I founded originally had three members but grew over time due to the fact that more people wanted to be involved, help and learn. Not all of them came each time but the central core unit ensured that it maintained momentum over the long term.
Base the group on continous improvement. There's nothing wrong with repetition, in fact reviewing, refining and improving is a great way to drive success. Having a group with a regular format that incrementally chips away at an aspirational goal can be better than trying to present and entirely new session each time
Link it to work. It sounds depressing but the fact is that groups that in my experience groups that are linked to achieving more aspirational goals related to the work people do have better staying power than more tangential topics. I think the reason for this is that people can still justify coming along when they are busy, and actually place a high value on getting away from hard busy work on something that they can reasonably prioritise.
Tie them to personal development - if you're fortunate enough to be in a leadership position then ensuring that people's personal development goals support and are supported by interest groups help to motivate people to attend. I used to establish personal development goals for testers to spend time researching testing topics, in order to present back to the testing team in regular 'lunch and learn' sessions. This allowed us to progress personal development, whilst learning as a group and maintaining momentum for the social cohesion that comes with informal group activity.
Pick a format rather than a topic - I had good fun with an infrequent session called 'Wednesday cinema' where I'd find short films on interesting subjects - process, technical, technique - and the group would watch and discuss them on Wednesday lunchtimes. It was a nice format that we could use to explore new ideas and concepts, the beauty being that any subject of interest could be included.

Alternatives to ongoing meetups

The key point of this post is not, however, to guide on achieving the goal of establishing successful long term meetup groups. Rather it is to suggest that this does not have to be the goal at all. Some initiatives don't need to have a long life to be hugely valuable to indiduals and the companies in which they work.

Rather than defaulting to a regular session, why not consider the following?

Simply having one session at a time and deciding at the end of each session whether anyone has an idea for another one. Once the handful of ideas that prompted the session run out, there's no embarrassment in stopping.
Agree on a much lower cadence than your initial enthusiasm might want e.g. quarterly allows four good ideas to see you through a whole year!
Brain-storm how many session ideas you have and establish a relevant cadence and expectation for the initial lifetime of the group based on that.
Have a slot for any interest sessions at all and let different people run different sessions without fixing the agenda

It may seem to you that there's no difference in the above and just letting something wind down. I disagree. There's a sense of failure that comes with having to cancel a regular session that is hard to shake. If this carries over into the same person not wanting to try to establish something new, this is a real shame. Personally I'd rather see engaged and motivated people maintaining their enthusiasm through trying some different ideas over time, than see them disheartened after their first endeavour doesn't last. After all a greater shame than a working group that doesn't last is one that never happens because no-one has the passion to try in the first place.

Photo by Jonas Jacobsson on Unsplash

Delivering Estimates and the 5 stages of 'good grief'

2019-06-18T23:28:00.001+01:00

It's an interesting characteristic of software development estimates that, while often requested,the results are rarely wanted. Clearly an estimate was wanted, however the the one delivered is often a far cry from the dreamed of time-scales and budget that the person asking for it had in mind.

I've seen this play out many times, none more so than when I was heading up the product function for a software agency that delivered large scale projects to blue chip clients. As I looked back on the many times I've delivered estimates and seen responses, a nagging sense of familiarity started to creep in. What I realised was that the reactions I've observed in people receiving estimates are very well described by the Kübler-Ross Model model ... more commonly known as the 5 stages of grief.

Stage 1 - Denial

"That can't possibly be right!"

"Of course it's not right, it's an estimate the clue is in the name, it's a best guess based on the information available" would be the perfect response when faced with outright denial, if it weren't for the need to be sympathetic with someone whose dreams of a major high quality software delivery in under a week have just expired.

It's ironic that the immediate response from someone who has asked for an expert estimate on a piece of work, presumably on the basis that the person is better placed to estimate the work than themselves, is often to suggest that it can't possibly be right. It happens a lot though. I've found myself bombarded with examples of 'similar' projects that were delivered in a fraction of the time - usually ones whose similarity extended to front end appearance but with a vastly simpler set of business rules.

Even when provided with an extensive breakdown of effort across the many parts of the delivery, the initial reaction to an estimate from someone who already had a number in their head is often to reject it. Anecdotally my experience is that the lower the level of understanding of software development, the more likely and pronounced this denial will be.

Stage 2 - Anger

The next stage of the 5 stages of grief is anger, and yes this matches perfectly with my experience.

"You're not trying to help" and "it doesn't feel like we're on the same team" are criticisms that I've faced in the past. These responses typically came after having been asked to estimate a technical project that carried such a vast level of uncertainty and financial risk that any realistic costing was impossible, for example the situation where I was asked to estimate the creation of an online 3D collaborative team gaming engine by developers whose experience extended to simple form based web-sites.

At this point it is worth remembering the consequences of undertaking a development based on a ridiculously low estimate

Strained customer relationships
Broken promises
Lost business
Lost money
Damaged reputation
Burnt out employees

Given that avoiding underestimating actually protects against these things, it's somewhat frustrating to be the subject of someone's anger when you try to do this.

Stage 3 - Bargaining

The bargaining stage of grief involves negotiating with a higher authority, or the events of the past, in the vain hope that the unfortunate situation can somehow be changed. In the stages of estimate grief it's pretty much the same, except the negotiation is with the person providing the estimate in the vain hope that the effort involved can somehow be reduced.

Here I'm not referring to a healthy negotiation of scope. That does happen but typically only once you've got further through the process. At the bargaining stage it involves asking if there's any way of getting all the things, but faster...

"You've included time for performance testing here, can we skip that?"

"Surely we don't need these administration or support capabilities"

The danger with these "What if we just did it quickly and badly?" type negotiations is that the "badly" is always forgotten at the point of release and criticism falls on the developing team when the barrage of bugs inevitably arrives. This is a dangerous time for projects as it's far too easy for the estimator at this point to be pressured into 'shaving' the estimate to make it more appealing - often without any justification other than pressure applied from a more influential role. It's a challenging but important process for anyone responsible for pulling estimates together to maintain their position and 'see through' the remaining stages to avoid simply kicking the problem down the road.

Stage 4 - Depression

Reaching the depression stage of grief is, according to this article on talkspace

an indication that you are experiencing your loss in the present, and more fully than you did in the previous stages of grief.

At this point the reality kicks in and, depending on the situation, this can lead to a level of despair

It may be that the person asking had already given an indication to a customer of a likely price
It may be that the capability was part of a roadmap that investors had bought into

Whatever reason, this is the point that realisation kicks in that it simply isn't going to happen as they first thought and it's hard to see a way out. It's a hard but necessary process to accept the situation you are in before you can identify the options that are genuinely available. I'm sure many an evening bottle of wine has been consumed coming to terms with the reality that your dreams of having that shiny new feature ready in the couple of weeks that you hoped, simply isn't going to happen

Stage 5 - Acceptance

If you deliver an estimate and see it through far enough to reach 'Acceptance' then congratulations. The fact is that it's far too easy to get bulldozed in the early stages of sizing development projects into artificially reducing estimates to a point that 'the business' are happier with. It's a sad truth that the comeback on the results of pressured estimates, delayed delivery, will be on exactly the same poor souls who've been pressured into agreeing unrealistic timescales in the first place.

The process of preparing and discussing estimates is an emotive one that presents a high risk of conflict and stress between different roles in a business. It's a liberating moment when discussion finally moves away from grieving over shattered expectations to accepting reality. Any estimate is merely the best forecast of the future that can be provided with the information available and the sooner that it is accepted, the sooner all parties can get on with working towards the a positive outcome.

Roadmaps Aren't Just for Products

2019-04-02T22:00:00.000+01:00

What's on your product roadmap? It's a common question to those of us working in software development and one that we're probably happy to answer, or at least find someone who can. I was speaking with a developer just last week for a potential supplier who was excitedly describing the new capabilities they had 'on the roadmap'. Despite my natural cynicism that comes from years of software testing, I'll confess that I do like roadmaps. The beauty in concurrently providing a vision of the future and the stages to get there whilst avoiding committing to unnecessary detail or deadlines - makes them far too useful to be restricted just to defining product feature sets.

What's in a good roadmap?

The use of product roadmaps to present our visions of the future is ubiquitous enough that there are entire books devoted to the subject. My favourite, is "Product Roadmaps relaunched" by Todd Lombardo which uses some excellent examples to show different ways of putting a roadmap together. As with any useful technique there are products designed specifically for the purpose, yet many find as much value from a simple Trello board or even a well structured PowerPoint. The format is far less important than what is being communicated, which boils down to some very simple messages

Here is our vision of what we want to achieve in the future
Some things we'll do soon and are in more detail
Some things are further off, are in less detail and are less likely to be done

This is a nice example from the Aha! site

I like the fact that it identifies clear stages of progress without unnecessary or impractical levels of commitment to timescales. What I really like is how powerfully a roadmap can bridge the communication divide and motivate the people responsible for delivering. It establishes expectation and vision but doesn't take the recognition for successful delivery and place it in the hands of a manager. The work has been identified but it's up to the team to set the pace and deliver the value.

What's not?

It's not about fixing dates. I personally avoid any tools that represent the roadmap in the form of a Gannt Chart or timeline like this

For me, this isn't a roadmap it's a project plan which has a very different perspective. For agile teams that respond to change, and are likely to encounter a lot of emergent need, baking expectation into a string of deadlines that they're unlikely to meet through no fault of their own is hardly inspiring. With a roadmap you're always moving forward. Conversely once a deadline on a Gannt Chart starts slipping then in my experience motivation tends to slip with it.

It's not just about adding value

In the field of software development Roadmaps are most commonly associated with the future feature set of a product. Software development teams aren't just responsible for adding features though. As I discussed in my post on different perspectives on value, successful teams need to have a balance of three facets of value

Identification of new value through new features
Delivery of value through maintaining pace of development
Protection of value through effective testing and identification risk

The traditional product roadmap revolves around the first column responsibilities here, yet to provide a true reflection of the responsibilities of a software company or team, all three elements here need to be included in their roadmap.

Improvements to architecture, infrastructure and tooling are needed to prevent the delivery of new value from slowing down as the capabilities of a product grow. It's a frustrating situation to be in where a solid roadmap of features has been identified, yet the ability to add new capabilities to the system has slowed so much that the new feature roadmap has to be severely curtailed.
A roadmap covering value protection, including testability improvements and test tooling/automation also needs to be considered. It may be that with a thin set of features and a small customer base a team can get away with very lightweight testing. As responsibilities and dependencies grow this is unlikely to persist and again the new feature roadmap will suffer drastically if a product starts to haemorrhage existing value through bugs and regressions.

Rather than being purely a responsibility of the product manager or product owner, I'd prefer to view the product roadmap as the representation of a collective responsibility in a development group to support healthy addition of value at a realistic sustainable velocity.

Roadmaps aren't just for software development

Despite their most popular guise, roadmaps don't have to relate to software development at all. I've also found them to be really powerful as a means to communicate and drive improvements in supporting teams or services. When building a support function years ago I worked with the team to create a roadmap of service improvement. Delivering the roadmap involved working from the introduction of an email parsing ticketing system to manage support through emails through to introducing a customer web based portal with on-line knowledge base and self-help.

I could have managed this through traditional project management tools and tasks, but that would have been a far more negative, command and control experience for the team. Establishing a roadmap together as a team shifted the perspective from an obligation on the team to deliver, to a vision of how they were going to improve their value to the business in the future that they could proudly present to senior management - a far more motivating and aspirational experience.

It's not the case either that roadmaps have to come 'top down'. For a team who are struggling to get buy in for improvements to the way that they work from management, a roadmap can be a powerful communication aid to support their desire to change. A team presenting their own vision of the future and how they can incrementally improve their ability to deliver value is much harder to reject than a team simply demanding large scale changes.

Vision and ownership

At the same time as defining a future of work, roadmaps also subtly define the relationship between a team or company, and that work. Created in the right way they can shift the perception of the future from something that is demanded of a team, to encapsulating a vision that they are bought into, and proud to deliver. This relationship provides a great reference point when discussing personal development, as you can communicate not just in terms of the current needs of the team but also in terms of how an individual sees themselves contributing to that future that the roadmap defines.

Sometimes something as simple as how work is presented can make the difference between individuals being inspired and motivated to deliver and feeling threatened and worried about failing. Having an outcome based roadmap allows you to motivate a team in improving value to the company while maintaining some flexibility and autonomy in how to achieve that.

References

The example roadmap images in this post are from this handy collection of excel templates from the Aha! website https://www.aha.io/roadmapping/guide/templates/gantt-charts
I recommend the following book as an excellent reference for what a good roadmap looks like "Product Roadmaps relaunched" by Todd Lombardo

Main Photo by Sylwia Bartyzel on Unsplash