Monthly Archives: October 2014

Defining a product roadmap – The pyramid of trust

The Product Roadmap is like the north star. The same way a sail boat is guided by a trustworthy, never changing light source, the Product Roadmap is there to give a team direction and comfort that they are moving in the right direction.

The goal

The goal is to get the team to be intrinsically motivated about the Product Roadmap. I’m making the assumption that if you’re reading this post you probably agree that selling a roadmap to the development team is a difficult undertaking.

In order to be able to provide direction and comfort, the Roadmap has to have the team’s buy in. In the remainder of this post I will describe the way I believe a team should be approaching the definition of a successful Roadmap.

The actors

The teams are made of a number of skills. Some teams can have just two tiers (or just one when the leadership is provided from whithin the team) while in larger organisations there can even be a structure such as the one below.

 Product Manager  Ultimately responsible with the delivery of the product
 Technical Lead  The technical go to person for the entire team (cross skill)
 Team Leader  Responsible with the entirety of a skill (e.g. developers)
 Team Member  BA, Designer, Developer, Tester, etc

In reality, the more tiers there are in a team the higher the risk that there will be voices that have not been heard or that certain individuals will end up not feeling represented. Later in the life of the product these are most likely to become the least motivated or the least engaged team members.

The approach

I believe that people’s motivation disappears when the Roadmap is enforced top down. Too much energy has to be spent on selling a roadmap epic as opposed to discussion the merit of that roadmap entry.

Instead, I suggest a bottom-up approach. I call this, the Pyramid of Trust. I will describe how this works by looking at a complex team structure. In a simpler situation, pyramid levels could simply be removed.

The Pyramid of Trust

The Pyramid of Trust … is built from the ground up

Step 1 – Ask the team

Everyone takes part in this exercise. Allocate enough time to allow people to collect ideas and to have a couple of minutes to pitch them. There are no bad ideas at this point. Think of it almost as a brainstorming phase.

This first step is also the most important one, because this is where trust starts being built. Here are some guidelines on how to approach it:

  • Remind the team about the company values / mission / priorities
  • Ask them to suggest a limited number of ideas (no more than 3). These ideas must be good for the product, for the end user, and for the business
  • Once the team have spoken, it’s time for their leaders to contribute with their own proposals
  • Lastly, the Product Manager / Business Owner is going to present their own idea

Step 2 – Find the themes

Realistically there will be many ideas that the team simply won’t have time to build. Some ideas might just be plain bad. Other ideas might need resources that simply are not available. These are just a few reasons why in step two, the Team Leaders should get together with the Technical Lead and the Product Manager to:

  • group these ideas by theme
  • discard themes / ideas that are not suitable

Delegating or sharing this responsibility with the Team Leaders is beneficial because:

  • it gives comfort to the team members who know that they are represented in the selection process
  • teaches the Team Leaders about responsibility and pragmatism
  • is a healthy process that enables excellent technical proposals to survive the selection process

Step 3 – Isolate the Epics

It’s time for the Technical Lead and the Product Manager to make the final selection for the Epics that will make it into the Roadmap.

This is the step where emotion is put aside and the business and the technical skills get together to figure out the best ways forward. At the end of this step the Product Manager will have mandate from the development team to pitch a Roadmap to the business.

The Technical Lead will need to figure out ways to plug the holes in the team’s skills set, resource and prioritise appropriately, find training and upscaling opportunities. All these will help the team be as prepared as they can be when they come about implementing this Roadmap.

Step 4 – Pitch the finalised Roadmap

The Product Manager is now under pressure from the team to represent their ideas when pitching this Roadmap to the wider business or to the stakeholders. Compromises usually need to be made and not everything will work according to “plan”. The bright side to this approach though is that the Product Manager will have the confidence to speak on behalf of the team knowing that if their suggestions make it into the agreed Roadmap then the team are likely to be motivated and engaged as they are, in fact, co-owners of this Roadmap.

Conclusion and next steps

It’s important to remember that if an idea that was generated by a team member makes it into the final roadmap, this person should be involved in the phases to follow: exploration, research, strategy, implementation. This way credit is given where it’s due, the sense of ownership and belonging is reinforced and this becomes a good example for the roadmap sessions that will take place in the future…

A good idea would be to make the roadmap as visible as possible, in a way that does not use actual dates. The focus should be on sequence more than anything. I would suggest three monthly updates on progress. These would also serve as reminders of the common team purpose.

Reboot

I need to put myself out there again. I am at crossroads with my career and I am hoping that writing about the decision making process and the context around it all will help me make the right decisions.

Relevant background

Instead of spending a lot of time and energy writing about my entire life, I will quickly summarise the last decade. Realistically, the last five years are the only relevant ones, so I will go into more detail as I approach current day.

2005 – 2009

About five years ago (2009), I was wrapping up my gig with Fronde Anywhere (a Mobile Banking & Finance pseudo-Start Up). I worked there between 2005 and 2009. My “consultant” title seemed to be the only generic term that could encapsulate all the roles I performed:

  • Software developer (Architecture, Mobile, Web, Systems Integration)
  • Trade Show presenter (e.g. CeBIT in Hannover)
  • RFP responder and integration partner
    • In New Zealand: ANZ, BNZ, KiwiBank, M-Co, Oracle, NZ Post, Telecom, Trade Me, Vodafone, Westpac
    • and abroad: BPI, Citi, Credit Agricole, Figaro, Sparkassen
  • Consultant and trainer (KiwiBank, CSC, Cap Gemini)
  • Marketing genius. Well not really, but I do take full credit for coming up with the Fronde name when Synergy International got rebranded

I soon realised that building software was just one facet of my technology persona. I also became aware that becoming involved with other businesses, and taking more product ownership was what I really wanted to do. Simply put, my view of my career and my priorities was somewhere along these lines:

  • short term: raise my profile as a Mobile technology person
  • medium term: build a popular Mobile solution that I would be proud of
  • long term: fill the gaps in my skills (leadership experience, design awareness, product mindedness)

The company I was working for was a good, comfortable place. However the challenges and the opportunities were not there so I had to make some changes. Without doubt, the most drastic change was starting Tmro. That was possible once I decided to reduce my work week from five to four days. I’ll dissect Tmro some other time, though…

2009 – …

The other change that I made was to take a job at Trade Me (2009). I joined as a back-end developer,  but at every occasion I was pushing the Mobile agenda. My .NET adventure was short lived. The contractor that had been hired to build an iPhone app was constantly asking for my support which was formalised within a few months. His contract wrapped up and I became the solo developer. We released the first version of the Trade Me for iPhone app sometime around Guy Fawkes (2010).

Trade Me Mobile

The iPhone app grew fast; so fast that within just a few months the Trade Me Mobile Team was formed, when Sam joined me as the Mobile Team Tester. Design was a separate entity altogether (It took a few years until the designers joined the developers and the testers to form cross skilled squads/teams as part of the larger Mobile Tribe/Team). The Mobile Team expansion continued by hiring two more iOS developers. We agreed to keep the developer to tester ratio as close as possible to 3 to 1. Before we knew it, we were investigating the possibility of building an Android app to repeat the success of the iPhone app. We did it ourselves, while building another two apps for a satellite business. With four apps to support we finally hired our own Mobile designer. This happened just in time for the first vertical app: the Trade Me Property for iOS app and the beginning of our bravest app: the Trade Me for iPad app. Things escalated quickly: in just a couple of years the app portfolio was growing. So was the team. What was shrinking was the time I was spending building solutions. I found myself doing more and more product advocacy (breaking business rules for the sake of making the apps better), arguing for resources, writing project plans and proposals, taking part in strategy meetings, and most importantly, managing people. The dream was coming true: my medium and long term plans were going great.

Crossroads

I did not anticipate was was about to happen next, but in hindsight it’s easy to understand how building a product suite, growing and managing an entire team, and representing these both internally and externally was going to transform me into a Product person. My job title said “Team Leader” but, in my heart, I saw myself as a Product Gatekeeper with a clear understanding that keeping the team happy was the first step towards delivering delight to our members. My vision was thus formed:

Only a happy team can build products that people love.

Despite attending WWDC (twice), Google Developer events, Rails camps, Webstock, UI/UX conferences, Agile barcamps, and more, I was quickly drifting away from being  just a software developer. My attention was constantly focused on the big picture rather than just the implementation detail. Most of the energy that used to be directed at learning new programming languages and development tools, was now invested in learning about what makes people tick and how to build products that people love.

Today’s turmoil

The Mobile Team is now large (approaching 30) and is made of a bunch of incredible people. There are five leaders who are amazing at representing their colleagues. Our skills cover Android, Design, iOS, Test, and Windows Phone.  We have outgrown Wellington (we are building a brand new team in Auckland). I sometimes wonder whether this is the largest Mobile Team in New Zealand. The products are more than just “relevant”.  Our official strategy documents require that “mobile is ingrained” in everything we do and this requirement is justified by fantastic stats. There’s a problem though: I want more. Currently, I find myself waking up in the middle of the night, taking notes and jotting down thoughts and ideas for a new Product that I have had in the back of my head for around four years now.

Reboot completed. Logging in…

I probably won’t be able to talk about the details of this Product for a while. I will write about the challenges that I come across and the decisions that I plan on making starting with the next post…

Engage, or not

You can do a number of things, too:

  • Nothing
  • Keep reading (subscribe to the RSS feed)
  • Submit feedback via my Twitter account or by using the contact page