One of my goal as our company’s tech lead is to keep our product moving and not be overtaken by our competition feature-wise. My hope is that it will secure our existing clients, by giving them the key feature only we can provide. I hope it also shows them that our application is the best and fastest moving among our competitors. Of course, the other goal is to acquire new clients by having the key feature they need/want.
Our company has seven people : the two founders (sales), the product manager (marketing), the account manager (client/operations), the template manager (operations/backend user), and the support person (tech support/user training), and me (tech lead). Of course, each person based on their perspective has their own idea on what we need to do to move the product forward.
The previous system was an ad hoc one: decisions were made one by one depending on the situation and who was in the room. It was inefficient.
Now, everytime someone has an idea or encounters a bug, they write a ticket to our Trello board, and I triage it. If it’s a bug, it gets solved immediately. If it’s a new feature, I do some research and evaluate the feasability and workload, then write down the steps to implement this change. Sales’ ideas come from questions and requests by prospects. The product manager tries and move forward on our long term product strategy and our app’s user experience. The account manager will often advocate for our clients’ direct needs while support will talk about the clients’ users’ needs. The template manager will push for the features that make his job easier and make him more productive. I try and make myself more productive - and will often push for the “cool” features, those that are fun to look at or fun to implement. While there is no guarantee that is true, the overall feeling is that this approach lets us improve all the important parts of our app.
Next comes the “Roadmap meeting”. We try to have them every three weeks. The trigger for the new meeting is the end of the previous sprint. Everybody comes. During this meeting, the product manager and I show to everybody the new features that have been developed and how they work. That way we ensure that everyone knows what our app can do as its features get added further. Any feedback can be added to a new Trello ticket.
After that, we go through all the tickets on our Trello board, and one by one, decide whether to add them or not to the next sprint. Following agile practices we try to have approximately 3 weeks worth of development in our sprints. Going against agile practice, we don’t just have one product owner, everybody gets a say. This hasn’t yet led to any problem, as our sprints are long enough to fit something for everybody, and short enough to allow everybody to wait for next time if necessary. Final call would go to the company’s CEO if it came to that, but that has never happened.
Most new features then go through to the product manager who will create short mockups that let me know how it should look and act (we use Balsamiq for that). Then I get coding ! When everything in the sprint is done, we have the next Roadmap meeting.
This system works pretty well for us. Everybody has enough of an input to have the app move forward enough on all fronts. Our product manager has free reign and ensures user experience and coherence, and I have a free reign in implementation.
What’s wrong with this system? A few things.
For one thing, the roadmap grows faster that we can implement it. This sometimes leads to morale slumps, as the team does sometimes feel that we aren’t moving forward, or aren’t moving fast enough. That may be solved as we increase the tech team size and overall productivity. For now, though, we have to live with it.
Also, we are completely unable to give a release date for any of our new features. As we are a B2B business, we have regular conversations with our clients and it can be frustrating for them to request new features and our response constantly be “It’s in the Roadmap, we’ll get to it as soon as we can”. We try to mitigate this by taking into account client feedback when defining the sprint as well as sometimes giving them release date goals (Q3 2013 for example) - on which we aren’t commited. We also let our clients pay to move features up in the Roadmap. That lets them decide on their own if what they want is important enough for them to incur the cost. As you can guess, most of them prefer to wait. Some however have paid.
These problems are however somewhat minor considering how much this process has let us move forward.
Hi, my name is Yannick Mahe, and I'm the CTO at Alveos. We write software that automates marketing for franchise networks.
If you've read this far, you may want to follow me on Twitter.
Being the sole developer at a SaaS startup 01 Oct 2013
Ensuring quality in offshore software projects 16 Sep 2013