So you want to get your ideas to market quickly. What we’ve learned is this:
You can’t achieve speed without having quality.
The reason is that poor quality causes problems. And those problems eventually slow progress down to a crawl.
We’re fully on board with moving quickly. In fact, it’s possible to use processes that deliver a product to market quickly whilst using enough quality measures to keep everything humming along. It’s about bringing ideas to life pragmatically at pace.
To some this seems counterintuitive. Surely if an app development team cut corners on quality, they can go faster? Yup. But this is going to come back and bite you.
“Speed without quality” is the silent killer. You don’t know it’s there until it’s too late. If your software team don’t pay attention to quality, you’ll see fast progress at first, but then things will start to slow down. This means that the cost will start to increase because everything is taking longer. And nothing works quite as it should.
This is the kind of problem that causes busiensses to abandon their investment and give up - it can just become too expensive and frustrating.
When creating a digital product, quality cutting is usual an invisible problem. Your product looks good and works well. Those problems eventually slow progress down to a crawl. This will happen over weeks and months.
Think of it as starting fast and then suffering a tiny continuous decelleration.
The main solution is to create an environment where people can do good work. And to work with people who want to do good work. This means they can factor in a layer of quality practices that only marginally increase the costs, whilst protecting the future of your investment.
Here are some examples of how speed without quality measures can hurt you, and some ideas to address the issue.
You’re getting frustrated because you ask for simple changes, but that causes other things to break. They take too long and cost too much.
The developers are using lean and agile principles to deliver new releases of your product every week or two. However, for whatever reason, they feel they don’t have time to do best practices such as unit testing or code reviews. The crappy code quality starts to make introducing changes difficult.
Talk to your software partner and ask them if their developers are happy with the code quality. Ask them if there’s anything more they can be doing to improve the code base to increase the pace of the project. If they don’t have skills or experience in best practices, ask management if their willing to train their developers or give them the time they need to get up to speed. It’s a win-win. Tell your project stakeholders that investing in some gradual code improvements will help improve the pace at which you can innovate, even if there’s a small cost increase.
Your product looks good and has the features you think your customers need. But it’s a bit clunky and the product isn’t resonating with your target audience. Some users might be complaining. Most of your users don’t come back for more.
It’s possible you’ve put too much emphasis on building your ideas rather than enabling your software designers to research and experiment. When rushed, designers may not feel they have the time or budget to build empathy with your target audience nor the essential research that feeds into the ideas phase.
Talk to your software team and ask if the designers have time to work in a way that can get results. Explain to stakeholders that good design translates to a larger user base and a more successful product. Ask them if they can recommend any research or validation activities for when you revisit or add new features. If you’re telling the team exactly what to design, you could consider trying to step back and let them get involved with the ideation side of things.
Work is overrunning. You’re not feeling like they’re “on it”. You notice various different people coming on and off your project. And each time they have to learn what’s going on, so you’ll end up spending time getting them up to speed.
It’s possible the product owner doesn’t have time to call meetings that look at the bigger picture and make a plan. So the team can’t plan a working schedule that actually fits what you need. All this last-minute scheduling is making people rushed and causing mistakes that increase cost. Your software partner might have people juggling multiple projects alongside yours in order achieve some progress.
Projects run much more successfully when people understand the bigger picture and can work focus on the problem in hand for decent chunks of time - think weeks or months. Ask your software partner to arrange monthly or quarterly road mapping sessions with your stakeholders so that everyone can see where things going and plan for it. Ask your software partner for block bookings of focused time. Include task dependency analysis in your workshops so that people have everything they need to deliver.
Pocketworks is about working pragmatically at pace. We want to help you take ideas to market, and more importantly, allow you to experiment with new ideas and evolve your product quickly so you can stay ahead. Your product needs strong foundations with just enough best practice to enable the team to build the right product at a sustainable and spritely pace.