Tag Archives: Roadmap

Improved – Get everything done

Over the past two years I have been working alongside my friend (and co-founder) Stef on Improved. Yesterday evening we released the first version to our friends and family.

I won’t go into what Improved is because its website covers all that; this post exists so that I can mark the moment when this all happened. Suffice to say, our vision is to

Remove the guesswork from finding the right person for the job

Some background info

People who know me closely are aware of the fact that I am a big fan of the Lean Startup model. Yet I just said that we’ve been working on this project for a couple of years, thus contradicting my previous statement.

Here’s my excuse: I have a day job, as Head of Mobile at Trade Me, and this job takes up at least 4 days of my week (sometimes I take work home with me). On Tuesdays however I get to work on what I am passionate about. For the past couple of years I have been spending my Tuesdays juggling work on Improved, with some other client work (for my boutique consultancy called Tmro), and with some other family activities.

This dynamic has kept my brain engaged at 100% and has produced an incredible amount of work related satisfaction (be it Improved, Tmro, or Trade Me). Without a doubt, all these companies / products have benefited from the experience I accumulated while working on the other ones.

Improved is the most recent initiative of this bunch, therefore it took a lot longer for the fruit of the work done on it to show. That ends today.

All in all (an including evenings and weekends) I’ve spent between 4 and 6 work-months building Improved. I am not counting here the effort and work poured into the project by Stef, who’s been doing a bloody awesome job in a similar 1 day a week arrangement for a period almost as long.

Stocktake

We decided to ship our MVP at the point where the platform supports the use cases we considered to be necessary (after doing plenty of soul searching and chatting to other people).

Roughly, these are the “features” of our v1:

  • The simplest possible create and manage Job flow
  •  Support two way messaging and quoting (including Push Notifications) between job owners and service providers (aka Improvers)
  • Search and browse Jobs and Portfolios
  • “Smarts” that support our vision:
    • photo doodling
    • take similar photo assistant
    • before and after comparison tool
  • Social login and straightforward account creation
  • Seamless Native app to Web handover
  • Clear feedback/review process

Apps side by side

Could we have done more? Absolutely! Our backlog is chocka full. Should we have done more? We think not. We want (and need) feedback from our users so that we shape the product into something that people love using.

After the first few user interviews we realised just how differently people think of their interactions around a job. Waiting longer and shipping a more “feature rich” product would basically mean increasing the number of assumptions made. This is a risk we chose not to take.

The next steps

Yesterday we started inviting Beta testers to use the app. We hope that everyone who uses the app (whether they have jobs they want done or they just look for their next customer) will find it useful.

We have an Android app underway, as well. I will shift my attention to finishing that app, while supporting the “early adopters” with anything they may need.

I’d love your help

If you’re reading this, chances are we know each other. Hi! You can help too! Get in touch with us by email and we will add you to our Beta test group. Improved is free for everyone to use, and posting jobs is non commital until you accept a quote (just like in real life).

Here are some other ways you can help:

  • you can upload DIY projects you have already done. This way we can learn more about the types of jobs people do, and the language they use to describe them
  • next time you need to mow the lawn, or prune a tree, or take classes or lessons of any sort, post a job on Improved. It’s free and you can build a pretty neat portfolio that you can be proud of
  • visit our website and send us any feedback you can. Is is clear what the product does? Do you like / dislike anything? Do you have any recommendations
  • spread the word. We have a Facebook Page, a Twitter account, and a Website. Please send our way all the to people you know who need stuff done around the house, who used a dog walker in the past, who took lessons or classes of any sort. Our mission is to enable people to be the best they can be at what they do.

Thank you.

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.