There are as many strident opinions on what makes a) a good Product Management process, and, b) a good Project Manager, as there are start-ups with Product teams.
Every team, I suspect, has fought to find their level and what works for them, and one team’s key learning is something that another team has learned to avoid. Rather than add to this noise, as part of this series I thought I’d present how we do Product at Hassle.com, and allow readers to take what sounds useful for their company – or avoid what doesn’t. This is the first of this blog series and will provide a broad overview of the Product management approach and tools we use here at Hassle.
Having said that, no ‘one-size-fits-all’, one thing most Product teams have in common is the need to adapt and change as the dual challenges of scaling and business imperatives press in. As a growing Product, Design and Tech team, we constantly review how we work, both internally and in conjunction with the business and operations, and therefore this is very much a point-in-time view. What follows in this series is a look at the usual lifecycle of a feature at Hassle.com – until we iterate and improve the process, that is (in which case, I’ll be back to explain how and why!)
In the last six months we have moved from a sprint to Kanban approach to Product delivery. While the structure of the sprint focussed minds about what the subsequent release cycles would bring to the business, there was a certain (self-imposed) pressure to make the sprint act as a meta-narrative of Hassle’s growth – each sprint needing to contribute in an holistic way towards company development, when, in actual fact, the growth of a Product is not always straight-up linear. At such an early place in our Product development, the stories and features varied in size and complexity, and while MVP was always a goal it was not always one we could constrain within the sprint boundaries.
We decided to try a Kanban approach, adapting the workflow columns to phases that fitted our requirements and preparing ‘just-in-time’ discovery sessions to ensure that the devs and designers knew what they were building and could start straight after completing their previous ticket, without too much ‘downtime’ between features. I’ll write more about our approach to Kanban in later posts – suffice to say here, we have found that Kanban has provided a good way of allowing us to manage a continual throughput of features and associated deployments whilst providing the flexibility to meet customer and business requirements.
In terms of tools, it’ll come as little surprise that Trello is used across the business to manage and describe/document the features (linking to Google docs / sheets / slides if required). Everyone in the business is encouraged to submit feature requests via Trello, and I hold a weekly meeting with the business leads to review (and challenge, if necessary) the prioritisation of new features and revisit the backlog. Trello’s simplicity is its gift, particularly when managing a complex backlog.
In addition to Trello, we built a simple Kanban tool in-house (during a Kaizen day – more on this another time!) to track feature progress beyond the Discovery phase. Called Shipp (after the Shipping Forecast), it allows for easy reporting to Chartio in terms of feature delivery (volume / duration) and allows me to track which devs/designers are working on what feature and which areas of the business are being served by the feature.
Finally, good old Post-It Notes and black tape on a white wall presents the latest view of the Kanban board and feature delivery to any team that happens to pass by, and provides the totem around which the team congregates each morning for our brief stand-up progress meeting.
In the next post, I’ll provide more insight into how we adapted the Kanban process and the impact it had on how we worked.