Do you know how software teams evaluate clients? What would you answer to some of these tricky questions? Let's break down the thinking that goes behind some of the common topics when clients talk to software companies.
How to start a collaboration with a software development company - Part 2
This article is part 2 in a two-part series about setting up a productive collaboration with a software development company. The art of asking the right questions will help you to choose the right dev team for your product. Click the links below to go back or skip ahead to the next article.
Our situation is the same as in part 1 of client handbook:
- You have a business idea or a need.
- You know the solution will likely involve software.
- You don’t have your own IT team capable of building the “thing” in time. So naturally, you think “Easy, I’ll outsource this”.
You now want to prepare well for talking to software companies. In part 1 we covered some of the basic questions you can expect to be asked.
In part 2, we’ll talk a bit more about questions that may have more nuance.
Many clients have a deadline in mind when they approach a software company. When asked about it, they state the deadline, which to the development team often seems... ambitious. The client is disappointed when developers say “What?! That’s impossible”.
In reality, it’s often a bit of a test on the part of developers. Tight deadlines are a reality in business, but they are an unwelcome reality when they are defined as such right at the outset and without justification.
A natural way to avoid this issue might be to set deadline at all, but then the devs will ask “Really? Don’t you care about the product going live anytime soon?”
If you define a specific date, developers may become defensive and require you to provide a reason why that specific day or week is crucial.
Typically the conversation goes like this:
Client: We want this kind of product to be launched in X weeks (months); can you do it?
Developers: No, and it’s not the question of how many developers you put on the project. Where are you flexible, scope or time?
Client: Neither.
Developers: Are you willing to work on the scope in a bit more detail to see if we can cut a few things? In our experience, a simplified solution might still work and be doable in shorter time.
Client: Fine, let’s give it a try.
Of course, this is rarely the first conversation they have; the team needs to learn about the business and the product before they can prepare an estimate. The point is, being inflexible on both scope and time is a big turnoff for good software teams because they don’t want to sacrifice quality. Developers have strong feelings about commitment to deliver by a certain date, and so they will hesitate before they know a lot about the product space and trust the client.
You will probably want someone to test the software. Whether you use manual or automated testing, it could be done on the software house side, it could be someone on your side, a 3rd party, or maybe some combination of these.
This is a trick question in the sense that you may answers “We don’t need testers”. Remember though that few software teams are used to producing great software without the help of professional-quality engineers, and they may get nervous.
You can say “We won’t pay you for testers, build it, do it right, launch it. It’s on you.” For the reasons above, this is unlikely to sit well with software companies.
You may want to say “Our team will test it”. However, bear in mind that this introduces an additional dependency for the development team - they need not just the product owner, but now also an external (from their point of view) QA team. Someone needs to manage the more complex setup.
You could also split the responsibility (some QA on your side, some QA on the development team side) - but then who is responsible for overall quality - supplier’s team? Your team? All this needs to be managed and impacts daily work. Communication complexity is growing.
Ideally, you’d follow the standard of having testers on the development team’s side and also retain someone on your end for user acceptance testing (which can be spread over the whole project timeline to minimize the impact on deadline and ensure frequent feedback from a larger portion of your stakeholders).
Software companies often face rejection at the last minute of the sales process, so, naturally, they want to see how committed you are. If you agree to pay them a visit, it’s not just a chance to build relationships, it’s also proof that you are treating them seriously. For you, it’s also an opportunity to get a feel for the company culture and meet the prospective team members.
The product workshop itself is also an invitation to do some discovery or preparatory thinking together before both sides commit. Developers want to see you in action, see how open you are to treat them as co-designers of the solution - if you just want them to code something, they won’t be as engaged.
Contact our business analyst now!
Because the software companies are rarely experts in every field they build software for, this is often a simple question to build an understanding of the domain. However, sometimes it is intended to test the maturity of your product vision and business model, and of you as the operator of that business.
Regardless, it’s best to explain how you evaluate the software’s impact on your business such that the team can look for ways to optimize their work: where to focus on quality vs speed, where to be extra careful, where to engage external resources for expertise, etc.
This is a test of the readiness of your organization to begin the project. Sometimes clients find it hard to actually begin the work quickly. It can be because you need some resources on your side (e.g. Product Owner needs to come back from holiday) or because your scope is not validated in the market just yet, so you are hesitant to pursue development right away.
This also is a way for the software company to test whether you are in it for real and have the money and organizational power to do what you say you want to do. It also identifies unexpected obstacles and reveals the possible contrast between declared required deadline and the realistic deadline, given starting the project sometimes takes weeks or even months.
It’s useful to prepare answers for these kinds of questions before engaging a software company. It will help you to initiate the work faster, and to establish trust with the team. The good news is that if you don’t know some of the answers, it’s usually safe to just admit that and work it out with the team.
Let us know if you know other tricky questions software companies like to ask their clients at the beginning of their cooperation, and what is your suggested response!
.jpg)