Stop starting over: Crafting the art of product development

The AWS Developer Lounge is often present at large tech events such as DTX, providing a place for all sorts of interesting discussions to happen. Sometimes it might be a Coding Dojo, others a more operational look at challenges in the tech industry. The variety of talks you can see in these sorts of places allows you to soak up lots of knowledge, from just one physical location, which is excellent! 

And around 2pm on Wednesday 17 May, a large crowd was gathering for a panel session, all about crafting the art of product development, with Rachel Lyons (Product Manager at Codurance), Rob Bowley (Technology Leader & Tech Advisor) and Anna Dick (Technology Leader & Tech Advisor). Here, we’ll summarise the discussion as well as adding some further thoughts which can be used to help organisations stop starting over when it comes to building a successful product. 

Building a product from the ground up

Building a product must start with the users. Understanding their wants and needs is a much more powerful exercise than building a product which you think they need. This might sound straightforward, but too often organisations have an idea of a brilliant product, but only look at that product from their own perspective. Embedding user feedback at the start (and throughout) the whole development lifecycle is crucial for a long-lasting and sustainable product. As well as understanding user wants and needs, you also need to continuously build, evaluate and evolve your product goals, and identify how you are moving towards them.

This means that at the start of the process, encourage developers and engineers not to go off and build things - rather provide consistent and concrete guidance on what the users expect to see from the product, and why they expect that. Be very clear about understanding the problem you are trying to solve for your customers. This could be through well crafted user stories, alignment sessions and regular demos to support your clear product strategy. Build those tight feedback loops from the outset. 

Simplify. You don’t have any idea at the start of development whether or not you’re building the right thing. Keep developments simple, and quick. Collect user feedback rapidly and use that to validate your proposition. By starting out small and validating your product at an early stage, you can be confident in building a roadmap for future developments and avoid costly rework. You don’t even need to build a system. Use UI tools to validate your offering without any coding at all. 

Begin work to validate your proposition

Having validated your proposition, you will soon be eager to start building right away. Before heading off and getting deep in the details, consider building a minimum-viable-product (MVP) to further validate your assumptions. The key here is to make sure your MVP actually is an MVP! 

It’s too easy for people to go off and look at the latest and greatest tools, or to build on your initial idea and develop further capabilities. Don’t let that happen! Focus on the smallest amount of work needed to show that your product will function in the real world. Nothing else matters. We can iterate and further develop it once its core value is affirmed and understood. 

With your MVP built, it’s time to start getting the product ready for production use. The key phrase that kept popping up in my mind through this section of the talk was automate. Automate everything you can. Reduce the manual effort to allow you to focus on what’s core to the product. 

First and foremost, this means building the engine of delivery. You will need to flex and adjust your product with continuous feedback coming in, so you need to enable the Build, Measure, Learn loop. To do that, build CI/CD pipelines, automate your testing capability, consider using well trusted techniques such as TDD and extreme programming. Log and monitor the tech you build, not just from a technical perspective but also measure product metrics to understand user behaviour. Act on it. 

Equally as important as setting up a mechanism for delivery is to understand your data and security requirements, and how these can feed into the process. Avoid the need for costly rework later down the line. These activities are easy to define at the beginning of projects, but retro-fitting them after 1, 2, 5 years can result in a mammoth effort to get on an even keel. Embed quality from the start.

Without these sorts of methodologies, your feature releases start increasing in size. Your lead time from idea to feature becomes longer and you quickly lose the ability to react quickly when you need to. Get it right the first time and you’ll benefit in the long run. 

Thinking about tech choices - don’t reinvent the wheel! Particular technologies are often popular for a reason; because they do the job. Use that to your advantage. Your product may be bleeding edge, but that doesn’t mean your tech has to be too. 

Use the tools available to you. If you need a survey for customer feedback, use tools such as  Survey Monkey.  Need a quick mock-up of some designs? Figma can help there. Before building anything yourself, have a look and see if someone has already solved that problem which you can benefit from. You also reduce the cognitive load on your development teams by working in this way, since you can reduce the amount of software they need to build.

With regards to workload, slice everything into very small chunks. Each task needs to be clear and well-bounded. Don’t leave things until later, they will creep up on you. Start small and iterate, iterate, iterate. Enabling this constant flow of change allows you to both develop rapidly and pivot at the exact time you need to. If the feedback says so, change direction (after all, your short release cycle will allow you to change back if required!). 

Finally, document your decisions. We at Codurance have spoken to so many people who have inherited a system, with little to no documentation. How can you develop a product if you don’t know why it’s been built in the way it has? Document all your trade offs not only to help others, but to help your future self when you inevitably forget why a seemingly small design decision was made, which had a big impact on the product. 

Scaling your efforts to support product development

With any luck, you’ll be in a position where you need to scale. To satisfy users, you’ll need to make an investment to build out your technical capability. Using your early feedback, you can begin to build a (lightweight!) roadmap and use this to shape your backlog. Then it comes to enabling the delivery of work. 

You have a couple of options here, aside from giving yourself ridiculous working hours and burning out. 1. Build an engineering team in-house or 2. Get a partner to help. The general feeling in the talk was to get a partner to help, unless you already have an existing capability which may be the case in larger organisations. 

Only recruit when you’re sure of future business. Partners can offer the flexibility both in terms of team size and skillset, which you might need during the ebbs and flows of early product development. 

Assuming you do go with a partner, you often pay for what you get. Whether you look at onshore or offshore partners really depends on your use case, since both have their advantages and disadvantages. 

When searching for a partner, make sure you know the right questions to ask to really understand if they’re the right fit for you. After all, they are joining you on your journey so you need to be confident they’ll be with you as long as you need them. 

For other sources of help, reach out to the community. It’s always impressive how much knowledge is freely shared, through meetups, blog posts and the open source community. It’s hugely powerful, there will always be someone willing to lend a hand. Just make sure to give something back in return. Host an event, contribute to an open-source project or write an article on your journey so far. 

Within larger organisations, it can be a little more tricky to be so agile and responsive to user insights. This absolutely does not mean you should reduce the focus on your end users and their needs; they are still just as important in a company of one as they are in a company of 10,000.

Things to avoid on your product development journey

The discussion then moved on to tips to avoid. It’s all well and good to say what people should be doing, but it’s also hugely important to know what not to do when starting on your product journey. 

You’ve probably guessed the first one… avoid building without getting user feedback. There’s no better way to tell if your product is on the right track. 

Secondly, don’t invest in something unless you’ve actually proved what it is and if it’s necessary. Your initial build only needs to take weeks, don’t spend lots of time or money building something that no one needs. It seems simple but so many organisations do this. There is a huge amount of waste generated building things that don’t actually target users. 

Finally, don’t forget to measure. Set your success metrics from the outset. Build them, measure them, then learn from them. Embed these into your development processes to understand how your changes impact end users. 

Key takeaways from the session

To round off the session, key takeaways were given by each member of the panel. Here they are (not quite) verbatim:

Rob: “Smaller is better. Build small teams, make small changes, develop small codebases”

Anna: “Don't underestimate the value of discovery phase, particularly with regards to users and obtaining feedback”

Rachel: “Don't get stuck in the details. Keep looking back and use the feedback to inform future developments and avoid scope growth”

Interested to find out more? 

Codurance offers support and guidance to help build your product in the right way, from the very beginning. Tell us about the challenges you’re having and benefit from our vast product experience. Our teams have supported organisations such as Cazoo, Envoy and Digital Theatre to deliver the right product, fast. 

Get in touch