Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.

Here, we tackle the essential topic of ensuring quality…

It’s easy to fall into a trap when it comes to managing the quality of software: an over-reliance on quality assurance (QA) at the end of the process.

While QA is vital, we strongly believe that quality is pervasive, and there needs to be a constant focus on this throughout a project. That also means always paying attention to a customer’s or user’s requirements. After all, there’s no point in building the best product if it doesn’t do what’s needed.

Because we always take this approach, we believe that quality is everyone’s responsibility all the time – from the developers writing the code, to the project managers, and even the customers we’re working with.

Doing this is not easy, and it requires a high level of commitment. But by operating in this way, as a single team, we can deliver outstanding outcomes together. Here are some of the most important considerations we always keep in mind when it comes to ensuring we create great software.

Understanding from the outset what ‘good’ looks like

Quality starts at the very beginning. That means the first discussion with the main stakeholders and really understanding their requirements. We then need to ensure the requirements are described in a way that’s testable, so we can validate whether the finished product meets the correct criteria.

We’ll then work with our development teams to check the written requirements are achievable and can be implemented with the right level of quality. Only once everyone is satisfied with this will we be ready to start work on a product.

Managing time pressures

It’s rare to have a project without some kind of time pressure – and of course that can compromise quality if not managed properly. So, as well as defining ‘Ready’ before we start a piece of work, we also create an agreed definition of ‘Done’. This will include the types of tests and reviews which must be completed before a feature is considered finished.

But, of course, unforeseen problems or scope changes do happen during a project, meaning that things can take longer than expected or need to be reprioritised. When this happens, it’s important to be open and transparent, and also to have courage – for example to explain to a key stakeholder that a change in the delivery schedule might be necessary.

I’ve seen organisations that have a very top-down way of working where people are too afraid to give bad news to their superiors, so they’ll do whatever is expedient to avoid it. Unfortunately, though, the upshot is usually that the management will eventually discover that the delivered product is not good enough – and they’ll wonder why. The answer, of course, is because of the culture in their business. Therefore, transparency and honesty are vital. After all, everyone is ultimately working to achieve the same goals.

Rigorous testing – after every small step

Although, as we’ve stressed, quality needs to be baked in right through the process, effective testing is still crucial. And it’s important to test early and regularly, otherwise a nasty shock may arise at the end – for example, realising an entire project is built on code that doesn’t work properly.

We use agile processes, breaking a project down into sprints that usually last two weeks. At the end of each sprint, we’ll carry out tests to ensure the software is fulfilling its requirements, working effectively, and conforms to the highest security standards.

We employ tooling to continuously conduct vulnerability testing and ensure software complies with OWASP Top 10 security standards. We put these tools into the build pipeline to ensure they are always running and developers know immediately when code is non-conformant.

We also use static code analysis tools to ensure the code we produce conforms to quality, reliability and maintenance standards.

And while our most experienced, senior developers are involved in these processes, again we also look to automate as much of it as possible. That way, a test can be rerun on a frequent basis – as software will always change during an agile development process – with no backlog building up.

Scalability and future-proofing

Scaling needs to be considered from the get-go – but there’s always a balance to be found. It’s easy to end up over-engineering a product so it can scale when that may not be needed for several years, if at all. But ignoring scalability can lead to its own problems if it turns out to be necessary.

It’s therefore essential for us to truly understand our customer’s needs so we can ensure the right level of scalability is built in. We’re also finding that public cloud gives us the option of scaling a product easily and rapidly, if required.

In addition, it’s crucial to consider the future maintainability of a solution – and this is often more important than the initial cycle of development. If quality is compromised during the build phase, maybe for cost reasons, it can quickly become a false economy as maintenance of poor software can be expensive and greatly increase the total expenditure.

In our opinion, automation is definitely the way to go when it comes to maintenance. But it’s incredibly hard to automate if the product hasn’t been built to high standards in the first instance – which further emphasises the need for stringent quality control during the initial build phase.

If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.

Iain Bishop, founder and CEO, Damilah

When it comes to thinking about new products, we often wish for more time to conduct interviews, analyze data, and explore competitors. But these tasks take up a lot of time. That’s where ChatGPT comes in handy—it can save us time and make our processes more efficient.

Let’s dive into the world of product discovery by tapping into ChatGPT’s vast pool of data and capabilities. This guide will walk you through how to use ChatGPT for a more efficient product discovery process, helping you prepare for the development of innovative products.

• 1. Start your discovery by focusing on either your business goal or the problems you’ve noticed for a specific group of people

Prompt you can use: “I have a business objective and I’m looking to identify potential customer needs aligned with my goal. My objective is [specify your goal]. Could you please investigate the potential pain points experienced by this specific target group.”

• 2. Understanding the problem or the unsatisfied need

Prompt you can use: “Can you please act as a Product Manager and explore the actual problem underneath these pain points? Please use the ‘5 Why’s’ method to find out why this problem is happening. Once you figure out the main reason, summarize your findings in a clear problem statement.”

• 3. Defining Jobs-to-be-done (JBTD)

Prompt you can use: “Could you please identify the top 5 crucial tasks (JBTD) that my target customers need to accomplish when dealing with the problem? I aim to gain a better understanding of the key activities customers will undertake, when facing the problem.”

• 4. Defining User Personas

Prompt you can use: “Could you please outline the three user personas who are likely to be my most frequent customers?”

• 5. Preparing empathy map for our target customers

Prompt you can use: “Would you be so kind as to create an empathy map for my target customers? I’m eager to gain a deeper understanding of their thoughts, feelings, what they see and hear, and what they say and do.”

• 6. Going through an Ideation process

Prompt you can use: “Picture yourself in a room with your team, including Software Engineers, UX/UI Designers, QA Testers, a Product Owner, and a Scrum Master. During an ideation process, what would be the three standout ideas as potential product solutions for addressing this customer’s problem?”

• 7. Defining a value proposition for our product

Prompt you can use: “Can you please define our value proposition for the first product solution? Describe how it meets customer needs, its unique benefits, and what makes it better than similar products on the market.”

• 8. Doing a market research and competitive analyses

Prompt you can use: “Can you explore other companies in the market selling similar products? Summarize their strengths and weaknesses and identify areas where we can gain a competitive advantage.”

• 9. Defining functionalities

Prompt you can use: “Please outline the key features for the product solution. Consider functionality, user experience, and any unique aspects that will set our product apart in the market. “

• 10. Defining the MVP

Prompt you can use: “Can you now please define the features and functionalities that are essential for our Minimum Viable Product (MVP)? Focus on the core elements that will allow us to deliver value to our users quickly and efficiently.”

To show that these prompts truly make a difference, we put them to the test in a real-life example. In this case study below, you can follow how we turned an idea into a possible product solution, with a clear explanation of our thought process.

At the end we’ll say that ChatGPT can be a really valuable asset in product discovery, helping us save significant time. However, it’s important to remember that while ChatGPT and AI, in general, can be incredibly helpful, they don’t guarantee the automatic success of our products. Success still relies on thoughtful execution and a comprehensive approach beyond the capabilities of AI alone.

Olgica Strezoska, Principal Product Owner at Damilah

To avoid building products that nobody wants, extensive Product Discovery is essential before embarking on the actual development process.

What is Product Discovery?

Product discovery is a dynamic and iterative process that lays the foundation for successful product development. It is the process that helps product teams understand the real problems and needs that people have and then figure out the best ways to solve them before starting development.

The concept of product discovery originated during the 1990s. During that era, companies allocated substantial portions of their marketing budgets to persuade customers of their product’s necessity. Unfortunately, this led to a lot of very expensive failures, as products often made it to full release before companies realized that people just didn’t need or want them.

The main goal of product discovery is not to ship features but rather to promote a continuous environment of learning that will help improve the product incrementally and consistently.

Product discovery is all about de-risking. As Marty Cagan puts it in his book “Inspired”, the purpose of product discovery is to address these four critical risks:

1. Value risk – Will the customer buy this or choose to use it?
2. Usability risk – Can the user figure out how to use it?
3. Feasibility risk – Can we build it?
4. Business viability risk – Does this solution work for our business? 

The product Discovery process can be divided into these 4 phases:

1. Understanding Users

The first phase is all about user research and building empathy for our users. We must be able to put ourselves in users’ shoes, and that can be achieved only if we truly get to know them, listen to what they are saying, and learn about their habits, desires, and frustrations.

To achieve this understanding, several steps can be taken:

• Conduct Surveys and User Interviews: Engaging with the target audience through surveys and user interviews provides valuable insights into their preferences, pain points, and aspirations. This step helps in identifying genuine problems that need solving.

• Continuously Ask “Why” (The Five Whys method): By consistently questioning the reasoning behind the product, teams can uncover deeper insights and align their solutions more effectively with user needs.

• Observe users and create empathy maps: By synthesizing and visualizing the data from user research and interviews, empathy maps can help us identify key insights. 

2. Defining the Problem

With a better understanding of the users, the next step is to precisely define the problem or need our product intends to solve. That can be done by analyzing the user research data we gathered and finding patterns that emerge from this data (using the Affinity mapping technique). By prioritizing the most important problems for users, the team can decide which user problem they want to focus on and clearly define their hypothesis before jumping into solutions.

3. Ideating and Prioritizing

Once we know what the user problem is, we should continue to the Ideation phase so that we can slowly come to the solution of the problem. This phase consists of gathering different ideas from the team (using brainstorming, mind mapping, or similar techniques) on how we can respond to the users’ problem or need. At the end of this phase, we have to prioritize the idea for which we are most confident it will bring value to the users so that we can continue prototyping and testing our hypothesis.

4. Prototyping and Validation

The final stage is about building a quick prototype to be tested and validated to gain confidence that the right product is going to be moved into the product delivery process. Prototyping ensures that the product solution aligns with the identified customer need and that users can navigate through the potential solution effectively.

Olgica Strezoska, Principal Product Owner at Damilah

Typically, the process involves reviewing the company’s technology and technical infrastructure, including architecture, scalability, security, performance and reliability of products and services.  Also understanding the people and their approach to software engineering, processes used and how closely they are engaged with their customers.

All software products, even new ones, tend to have technical debt, which may vary from areas of the code which may need refactoring to support scalability/performance future requirements to utilizing out of date or even obsolete versions of third party products. It is important that engineering teams have an understanding of their technical debt and a plan to manage it.

Modern software product teams tend to invest in devops and automation of both their delivery pipelines as well the testing of software. This is sometimes difficult and expensive to reverse engineer into long established “old tech” products, but is likely to be important to resolve if these products are expected to change significantly as part of the investment thesis.

It is also really important to review any major work-in-progress projects, especially where technology which is new or unfamiliar to the engineering team is being used, for example where public cloud is involved. Public cloud offers many opportunities to introduce time and money saving infrastructure as a service, but used in the wrong way may in fact incur significant additional costs. Understanding best use of cloud and the opportunities presented may be important to support value creation opportunities.

One of the biggest challenges I hear about when talking to investors occurs when they receive the Tech DD report from one of the third parties who have productised the process. Lots of analysis and data is presented outlining all the various potential areas of concern in a neatly structured form.

The question is then “So what?”. As a CTO what would concern you? I have been involved in many Tech DD activities as a CTO, either whilst performing that role on a full time basis, or as an independent consultant asked to advise an investor.  Being able to see the wood for the trees and raise red flags is an important part of the role, as well as looking for opportunities to improve productivity and customer engagement.

Assimilating all the data and turning into a workable plan can be quite a task depending upon the size of the organisation. Sometimes the selling business is deliberately obfuscating with information, which itself tells a story or denies access to key technical people so as not to unsettle them.

At Damilah, we have extensive experience conducting technical due diligence activities, particularly for product software companies. As product experts ourselves, we understand how to build a great product and the day-to-day challenges which may occur.

We have deep technical expertise of legacy applications as well as modern cloud SaaS products and understand the needs of investors wishing to create value and scale businesses they acquire and what the barriers to these may be.

We also have teams of highly talented software engineers able to tackle the most complex transformations from monolithic to micro-services, or from on-premise to cloud native SaaS solutions, working closely with existing client teams. We adopt a modern agile way of working , to deliver maximum value to the customer in the shortest possible time, with full visibility for all stakeholders.

In particular we have extensive experience of working with Private Equity houses and their portfolio companies, understanding well the need for value creation to support the investment thesis, having worked ourselves in these environments.

To discuss further, please contact iain.bishop@damilah.co.uk.

Iain Bishop, CEO and Founder at Damilah