December 11th, 2024, posted in for_founders
by Adelina
Product discovery is the first part of a software product building process. And since it marks the beginning, the way you do it can make or break the final product. This is where the project is scoped out, where its look and feel is mapped out and when estimates are made.
Product discovery marks the foundation of your software product, and it’s used as a reference when the development process begins. How well product discovery was done will determine how efficient the coding process is: if the app is fully designed, all the flows are mapped out and the developers have a clear idea of the features, coding won’t be such a difficult process.
In our case, we’ve gradually moved onto design-driven development. This means that we put a lot of effort into creating the final design of the app before it goes into development, so that the look and feel of the app is approved by the app stakeholders before we go into costly months of coding.
This methodology ensures that the app is scoped out more accurately. With a fully fledged design, you can write accurate user stories with all details needed. The design will help a development team understand the app flows and how everything clicks together.
Now, putting a lot of time and effort into product discovery doesn’t always guarantee a smooth development process. These projects have stakeholders, and their decisions can make or break the entire process. So in this article, we wanted to highlight some of the mistakes SaaS founders make during product discovery, which can negatively impact their projects. For those looking to see how well their discovery and design process stacks up, we’re offering a free UI/UX assessment to identify key improvements that can strengthen your product’s foundation.
Inefficient or lackluster communication
When outsourcing software development, as a SaaS company, communication is crucial. You don’t know these people. They’ve been recommended to you and you’ve just met. You discussed your project and its requirements and they can build it for you. But they don’t know you personally, and they can’t possibly get to know you entirely through a few meetings.
This warrants good communication, which goes both ways. Software development companies do this all the time, so we know how to open communication channels with app stakeholders. We either use email or Discord or Slack. Development tasks can be shared with the stakeholders through ClickUp, where they can also leave comments. Designs are shared through Figma, which also has a comments system.
So where does it go wrong? You guessed it, on the stakeholder’s side. That’s what this article is about, after all. There’s not much use in opening communication channels if the software development company is the only one using them. To ensure an efficient product discovery process, we need to be able to ask questions, and to receive timely responses that give all the information we need.
During product discovery, we’re mapping out features and flows - and some of our choices need approval, so that the app stakeholders don’t end up with features they don’t want or need. This means being available to talk and not taking too long to reply (“too long” being more than a week).
A common pitfall here is not getting answers to all questions asked, or getting answers that don’t give enough details or which aren’t explained well enough. Not everyone is perfect at communicating, but when hiring someone to code an app, it’s crucial to have a constant and efficient exchange of data while working together. Especially since the outsourced company is just now learning about the SaaS founder’s business.
So how do you avoid communication issues in software development? There are 2 ways we usually fix this issue:
- Holding meetings to discuss the app scope and features, and any questions we might have. In our case, we usually present our designs in stages, which is a great way to brainstorm and to make decisions regarding the app flows. In such meetings we also discuss any confusions we might have. Talking often makes it easier to get information across, so this is often more efficient than talking through email.
- We give follow-up questions when we don’t get enough information to continue. Rather than playing a guessing game, we try our best to ask the right questions in order to get the info we need.
All in all, to ensure better communication, as a SaaS founder it’s crucial to be clear, transparent and timely. Communicating your business needs will make it easier for your technical partners to build an app that truly fits what you’re looking for and which best serves your key audience.
Not knowing what they want
When hiring someone to build an app for you, it goes without saying that you need to know what you’re building in the first place. A general idea of what you want isn’t enough - this means that we’d have to fill in the blanks. And we definitely can, but we can’t guarantee that it’ll be what you really want.
Before even getting in touch with a development company, you need to map out what you want your app to do. Start with a few goals users need to be able to achieve within the app, a list of what kind of users the app should have, and then take those goals one by one and think about how you want them to be fulfilled.
Since your app, as SaaS software, will offer a service, you need to focus on what you’re actually offering. How will your app assist users in fulfilling their goals? Once you have a detailed answer to that, you can move onto visual requirements: how do you want to look? If your company has a visual branding, should the app follow that?
When it comes to design, your chosen development company can fill in the blanks and come up with something. But if there’s a certain style you like and you want to see it in your app, it’s best you let them know from the start. Make sure to think that through beforehand and prepare any examples before the design stage begins. Otherwise, you might receive designs that you don’t like.
There are also cases where SaaS founders don’t realize what they’re actually looking for until they see a finished design in front of them. In those cases, they don’t really know what they want, but they’ll know it’s not the design they’ve been shown. That kind of workflow isn’t very productive, and it can lead to endless design reiterations - and these, in turn, take a lot of time and money.
Overall, not knowing what you want means spending extra time and money for your chosen software development team to figure out how your app should work. When sometimes, deep down you know what you want, but you can’t put it into words. Take your time planning things out before hiring a team, and keep track of the ideas you get during that process. And if you’d like a second set of eyes on your design readiness, take advantage of our free UI/UX expert review, which can help you solidify your ideas before starting with a development team.
Changing their mind after approving things
Product discovery happens in several stages, and usually at the end of a stage you get asked for approval. With our methodology, that means approving a certain amount of screens, which involve a series of features and flows that will go into the final product.
Once certain screens are approved by the app stakeholders, in our eyes those features are final, and will be turned into user stories. These will be used by developers in order to turn those screens into a living, breathing app. In other words, once something is approved, we won’t make any changes to them.
One issue that can arise in product discovery, especially when it takes a long time, is that stakeholders will forget about features they approved one or two months ago. They’ll see those again while going through the design, and they’ll decide they don’t want them anymore, or they want them changed.
Changing your mind is only human, but in the case of software product development, switching up on a feature can lengthen the duration of your project. If you’re sure you want to change something, be wary that it’ll take time to apply these changes and it can’t happen overnight.
If you change your mind on certain features, that means redoing the designs for those screens, and if user stories were written already, updating those to match the changes. This will, of course, take time. If you change your mind after the development estimates have been done as well, that sets you back even more.
Of course, this doesn’t mean you can’t change your mind about the project scope, especially if development hasn’t started yet. But it’s more efficient to fully discuss features when you see design iterations, and approve everything then. Otherwise, be prepared to wait a bit longer for a working version of your app to be done.
Not trusting professional advice from their technical partners
There’s no denying that SaaS founders will know what’s best for their business. They built it, so they know what it’s supposed to do. But when working with a software development team tasked with bringing their ideas to life, they need to be mindful of the team’s ideas and advice.
When hiring an entire team of people to build a software product for you, don’t forget that they’re all bringing their experience and expertise to the table. With those, they’ll be able to advise you on the best ways to approach your technical needs.
Since we’re talking about product discovery here, this means that your technical partner will be able to advise you best in terms of design and user flow decisions. They’ve built many different apps already, they know how the development process goes and what kind of issues can appear along the way, and they’ve also tested such apps manually and learned what works and what doesn’t.
As much as you know what would work best for your project, when it comes to the technical, pragmatic side of things, your partners will know best. Especially if they have complete user research to back them up.
Despite this, some SaaS founders can be inclined to insist for things to be done a certain way, even if their technical partners told them it’s not a good idea. This can cause friction between the SaaS company’s team and the technical partner, as it builds mistrust, and it can also lead to a final app which doesn’t fulfill its goals as it should.
Afterall, software development teams won’t choose to build your app a certain way just because it’s easier, but because it’s better - they’d have your best interest at heart. And when they suggest how to proceed, you must keep that in mind.
In terms of usability and user flows, especially, an experienced team of UI/UX designers will know best on how to design your app. You can give directions, but it’s very unproductive to ask for the opposite of what they suggest. If they tell you a certain flow works better and they have solid arguments for that, hear them out before you say no. Or be open to a brainstorming session so you can come to a middle ground.
Not treating their technical partners as partners
Software products can take a long time to be built, which means working closely with a development team for several months up to a year or more. From what we’ve seen, keeping a professional, productive relationship between development teams and project stakeholders goes a long way.
Treating a development team as partners, collaborating with them, being nice to them, can help the team work on your project with pleasure, which can bring better results in the end. Doing the opposite means creating friction, instilling fear, and turning software development into a chore. They’re still human after all, and their emotions can affect their work.
Doing this the right way means collaborating with your technical partners, respecting them and their opinions, and keeping a professional, light-hearted atmosphere while working together. That, of course, as long as they give back the same treatment.
This can be difficult when a technical team keeps making mistakes. Not getting what you’ve asked for when you’ve asked for it can be frustrating, especially if you communicated it well. In that case, stay professional and talk it out with your team until you reach an agreement. But if nothing works out, consider hiring another team that’s a better fit for you. Cultural differences can interfere here, so consider looking for a team with a similar culture to yours.
Another thing that can happen in such situations is micromanaging. Since product discovery involves a lot of design, SaaS founders might be inclined to get very involved in the design process. Down to specific styles and colors. This can be productive when done well: if you want to get extra involved, do so over meetings instead of emails. Working together and getting your point across verbally can go a long way, as emails can seem too detached.
In such situations, SaaS founders can schedule regular meetings with the designers where they can discuss visual components and brainstorm ideas. The final goal being reaching an agreement on what the app should look like, down to the very last detail. Trust that the designers will know best, since it’s their job - but as an important stakeholder, your opinion matters as well. The key here is respecting each other’s points of view and being open to discussions.
And there you have it, these were a few common mistakes SaaS founders make during product discovery. As we’ve pointed out, working together professionally, respecting your technical team and brainstorming ideas together can help you build better software products.
Looking to start product discovery on your own software development project? Contact us and we can have a chat about your ideas.
