It’s agile.. innit?
Building digital products is bloody difficult. But like anything in life the more you do it the better you get. We've now helped to build almost 20 businesses, advised on at least that many again and learnt a huge amount along the way. Of course, the learning journey never ends but it's fair to say the way we approach things now is almost unrecognisable from the early days.
Our body of work consists of products we've built for ourselves; Slate, recently acquired by Source Creative, Conjure, Votd, two versions of our proprietary CMS as well as commissions for Jukedeck, Altitude Music, Bulb, Everpress, Kickr, Couverture and the Garbstore, LSN, two for reasons of client confidentiality that we're not allowed to talk about, a couple of early attempts we'd prefer not to talk about, let's call them a learning curve, as well as three absolute belters currently in development.
Creating your own products, where you have full product ownership and control of velocity and budget is one thing but building them for other people is something else again. There are of course the same strategic, UX, UI and technical challenges to overcome in order to achieve product market fit but equally, if not more importantly we have to pay even more attention to communication so as to manage the expectations of our partners, especially when they are non technical. Custom software isn't a thing that can be bought off the shelf it's the result of a clear collaborative process.
One of the privileges of working with passionate, driven entrepreneurs is that we're not just dealing with briefs, objectives and specs but long held dreams and aspirations. Visions for a better future both for the end user and themselves.
Not surprisingly their dreams are ambitious. Many have pre read excellent books like Osterwalder and Maurya's classic text, 'Lean Canvas', Peter Thiel's excellent 'Zero to One', or in my opinion, the even better 'The Hard Thing About Hard Things' by Ben Horowitz and can't wait to change the world.
In this context their zeal frequently leads them to wanting to create a beautiful all encompassing product containing every possible feature from the outset, with little appreciation for the depth of scope, time, cost and financial risk that would entail.
As a service business we love to excite and delight and in the early days we equated that to saying yes and then doing everything we could to deliver. Sometimes becoming intoxicated with the potential for an idea rather than creating simple rapid prototypes that could be tested with users. We were perfectionists in a world where perfection doesn't exist and real life users are the only meaningful critics.
We learnt that no amount of late nights, hard work or effort could build Rome in a day. The result was a knackered team, often unhappy clients as a result of missed deadlines, not to mention the stratospheric stress levels we were under from the financial hit we'd taken from committing to deliver features for a fixed priced.
It was an unholy trio. Partners that were getting lots of time for free, yet frustrated with the service, a team stretched to the limits and a business that was struggling to keep its head above water. It could quite easily have been game over.
How did we get into such a mess? Well, largely because our initial forays into product development were to all intents and purposes based on a Waterfall methodology. We'd built scores of small applications successfully this way before. We'd take a brief write a spec and then build it. Easy. No?
While we had the UX, UI and tech talent to build products we quickly realised that a sequential approach moving from spec to UX to design to build was incongruous with the ever changing requirements of building products in the real world. Ever more so when time is tight and budgets tighter.
Although totally necessary, the move to agile / scrum wasn't easy and took some time to bed down because it needed the whole team to adapt. No more locking yourself away and solving the problem by yourself. Agile necessitates working in tandem; UX and design with the development team for rapid prototyping. Such close collaboration might mean individual compromise but the team is collectively working towards a shared goal and it invariably gets there quicker. Needless to say it's now the bedrock for everything that we do.
But even with the work flow sorted in our experience successful product businesses can only be built in full partnership with the product owner i.e. our customer.
Partnership is any easy thing to say but more difficult to deliver. It means having those difficult conversations early, frequently committing to less rather than more, explaining options and their trade off's. Do we rapidly prototype now for MVP (invariably yes) but potential build up technical debt for the future? Is it best use of time to create tests that provide 100% coverage when features and functionality might change from Sprint to Sprint or wait for the feature to be complete?
When problems arise, or velocity or costs change, which they frequently do, it's essential that the reasons are fully explained and the team does everything it can to mitigate the impact. Equally, no matter how committed we are to the project it's essential for partners to understand that we can't work for free. We only sell our time and that needs to be covered. Ultimately, it's all about trust.
How you build it? Well that's something we're always learning too but here are a few pointers we picked up along the way:
- Be completely transparent. Never tell the partner what you think they want to hear either to win the work or when delivering it.
- Working to a budget is fine, working to deliverables is fine, working to timelines is fine but committing to all three at the same time for anything more than a two week sprint is rarely realistic.
- Climb in each other's wheelbarrow. Focus on your partner's priorities but ensure they deliver to yours. Client supplier relationships don't make for successful product builds. Partnerships do.
- Think about roadmaps and not starts and finishes
- No matter how much or little money you have don't think cost, think value.
- Never do it for the money. If you don't believe 1000% in the product or founders stay well clear.
- MVP's are not Enterprise products and should be approached differently
- Be super clear about who is the product owner and ensure they understand their role. No matter how involved we are we can only ever be the surrogate parent.
- Release early and release often.
- Smaller and simpler is better
We love building products. As a team feel we have the best job in the world. We now combine a skilled team with the experience and well honed processes that maximise the potential for an MVP to become a successful business. Our agile journey has been the natural evolution and maturation of our proposition and we couldn't be more excited by our new website and the opportunity for sharing our passion with the world.