Mercenaries vs Missionaries

I have been in meetings discussing product road maps or simple ideation sessions where I find the people involved inadequately equipped to make the right decision. For a long time, I thought that it was me who couldn’t bring in-depth knowledge of Tech and Design to the table.

But then I came across Inspired 2nd Edition and I was introduced to the idea of Mercenaries vs Missionaries. Basically when the product decisions are made without involving the designers and developers then we are essentially asking them to execute orders as if they were mercenaries being paid for their services.

The goal here is to come up with practices that will allow designers and developers to be an integral part of the product decision making process. When people are working towards larger business objectives instead of working on a specific feature on the road map then they become missionaries.

The core idea introduced by Marty Cagan is that you involve developers early on in the product discovery process and changing discovery process to make it more agile. In my experience it is tough to throw a book at the leadership and ask them to change the process. But I have found certain small steps very useful to bring about the change in overall process and ideology.

Involving developers early on in the discovery process

• The least you can do is keep them in the loop. When my CEO showed reluctance to include the UX guy in discovery process, I decided to keep him in the loop by providing him regular updates. Letting them know what kind of ideas are being considered allows them to at least communicate their concerns through you and it also ensures that they can work on their current deliverable with the larger picture in view.
• Communicate business objectives. A lot of times things that make a lot of sense to the leadership make little sense to the team. Communicating business objectives to the team and letting them empathise with the leadership ensures that the team shares the vision of the leadership and can be enthusiastic about it.
• Expose them to users. Include your team in user interviews. Let them talk directly to users who face some specific problems. Share user insights with them. Sharing a user recorded video about a problem with developer once led to a unique solution that both designer and I hadn’t thought of.
• Brainstorm and Validate with them. As I said above, a lot of times you will find yourself inadequately equipped to answer some questions. I have found informal discussions with the team regarding ideas that are being considered very helpful. Validating feasibility and usability issues early on helped us reduce our delivery cycle, maintain consistency and in long run changed the approach of leadership towards the discovery process.
• Be open about results. People lose direction if they don’t know whether what they are doing is producing any results or not. Sharing both success and failures of a release with the team and discussing the next iteration ensures that the team doesn’t lose its confidence and direction.

Using an agile discovery process

When you are following a road map and a few things go wrong along the way , it doesn’t make a lot of sense to continue following the plan. The designers will start having trouble managing a consistent flow across releases, the developers will end up having a lot of tech debt they want to resolve and either will want a break from back-to-back releases. At least those are some complaints that I have dealt with.

• Discuss your road map with your team. Before you lock your road map discuss it with your team. Explain each feature/release to them and let them provide feedback on constraints involved, time required and dependencies. Sometimes it may make a lot of sense for developers to build one feature before other because it makes their job a lot easier and can save them a lot of time in tech debt.
• Define dependencies. If a feature fails to deliver the expected results then it won’t make a lot sense to develop features that are related to it without fixing it first. When such dependencies are identified early on then you can update the road map to iterate over the primary feature before getting into development of next feature.
• Allow time and scope for fixes. I used a process where we spent some time after a release to identify tech and UX debt in last release and plan fixes for them in one of the upcoming releases. It allows the developers and designers to have better control over their work without disturbing the release cycle.
• Validate before building. If there are any concerns about a feasibility or usability of a feature then validate those concerns using prototypes before building actual product. This ensures that you spend less time on bad features and more importantly you won’t be irritating your developer with the question “how much longer will it take?”
• Learn and iterate. It will be great if you can allow space in your road map to iterate over features that didn’t work as expected. This will allow you to get more out of subsequent releases and it also ensures that you are using your learning right.

It would be great if you can follow the principles outlined by Marty Cagan as the standard practice. I for one has found it tough to convince the leadership of such a major change. But making small changes surely help in adopting those changes in long run.