This article is part 1 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 increase the success of your project and find the right fit for a software development partner.
How to start a collaboration with a software development company - Part 1
Click the links below to go back or skip ahead to the next article.
Say you have a business idea or a need. You know the solution will likely require software. You don’t have your own IT team capable of solving it in time, so you think: “Easy, I will outsource it”.
You also don’t just want a few individuals who need to be managed. You prefer a team who will get it done with minimal impact on your organization.
So how do you prepare for buying the services of an IT team or an IT company? Sure, you can ask for recommendations, browse LinkedIn, get some contacts, but what’s next? What do you tell them?
To enlist the right team you’d best be prepared. A good software development company will ask you a lot of questions. Some of these are pretty standard and easy to answer, but others can be tricky. If you don’t have good answers, you may have a hard time finding a good supplier!
Let’s work through some of the common questions to get them right, and to build an image of a solid partner right off the bat!
Here’s a list of 6 basic questions that an IT company will usually eventually ask, and some of the reasons why they are being asked and what’s a reasonable answer.
Sounds simple. If we (the IT company) are to build something or propose a solution to a problem, we’d rather understand what your world is, how it works, because it brings basic context to any further discussion.
A bad answer would be “didn’t you look at our website? It’s all there, let’s not waste our time”. It’s bad because typically you are the expert on your business, and the supplier isn’t. Even if some of their IT guys worked in the same industry, there’s depth and history behind your business and you shouldn’t want them to waste time trying to piece it together from various sources. You should also show that you are willing to coach them on some more nuanced aspects of your business and that there are passion and engagement on your side. If you say “let’s go straight to technology” you will sound like someone who’s in a hurry and not the best partner to work with.
A good answer will summarize what your industry is about (don’t assume IT guys know anything about your industry!), who your clients are, what your product/service is, what’s the basic business model/revenue source, and which part of the business they are supposed to impact.
Clarity really helps in planning software work, and as the client, you will be the best source of clear input for the IT team.
What is it that you want to build? Why do you want to build it? What do you want to see happen after it’s launched?
There are all connected and it’s best to combine the answers into a single story.
It’s important for the IT company to know not just the specific software product you are interested in building, but to also understand the rationale behind it. It is possible (in fact, common) to get great solutions from IT teams when they understand the specific business challenge. They often come up with a much simpler, down-to-earth, more direct solution to the problem than the solution imagined by the client. You don’t have to guide them that way, but it can be a lost opportunity.
It also makes the conversation much richer than just talking about possible features for an app.
A good answer will summarize the issue and explain why you thought of a particular type of a solution already, e.g. “We are scaling our organization but one department is lacking behind due to lots of manual processing of paper documents. We need something that will make them efficient without adding more staff. We think a system with a digitized process for some of their work will be perfect for this.”
There are two broad reasons this question is asked.
First, the IT company wants to know as much as they can about your world and the work to be done. The more they know, the smarter their answers and solutions will be, because they will understand the field and your unique situation.
Second, they want to understand your commitment and sophistication as a client. They are testing you. Are you talking about a loose idea? Have you thought the problem through? Have you already hired some professionals to design something? What kinds of possible solutions are you considering? Maybe this is your third approach to make a dent in this market and you know it very well, or maybe you’re new to this, which is it?
A great answer will explain that you have specific goals and ideas for related features of the imagined solution, and will maybe even include a UI prototype or a similar application you saw on the Internet.
A reasonable answer would be to say that you haven’t worked it out just yet, but you will be able to guide the team in designing a solution, and you can share a 1-2 page document which describes the goals and features of the solution you are after. The fact that you have taken the time to write it down shows a certain level of commitment on your part.
You could also just spend a few hours with the IT team walking them through the idea, either on a video call or in person. Workshops are a great way to clarify goals and brainstorm or improve solutions.
A bad answer is one where you state that “oh, it’s just an idea”. Experience tells us that this is usually too early to engage with a software development company unless that company has a strong consultancy/product/UX design/business analysis team which will guide you through the process of converting an idea into a workable product proposal/design. This is significant work though and often has little to do with software.
The challenge of only having an idea isn’t just conceptual (“let’s figure out a solution”). It’s mostly the organizational work within your company that needs to happen. It’s a lot of discovery, negotiation and decisions to be made before a project/work can start unless you are a small company and can initiate new work at will with few negative consequences!
Finally, there’s a controversial response in the form of a long, detailed specification of what you want. Pages and pages of detailed requirements. It can be a blessing because it’ll let the IT company decide whether you are a good fit or not, and will help them prepare a good proposal with an accurate estimate. But it can also be an issue if you imagine that you will get a system exactly as planned.
Unless such a detailed specification was well above average in terms of quality and you want a small product, the actual solution will always deviate from what someone initially came up with. It can prevent the IT company from using their expertise in helping you because if someone already worked out a solution in great detail, IT company is reduced to an execution-only role and you position yourself as the main designer. This is not the best relationship to have with a software house full of young, eager minds potentially with a number of specialities such as programming, product design, User Experience design, quality assurance, project management, and more! The consequence is that the best IT teams will be reluctant to take on work of that kind. They want hands-on design work during the project, working closely with their clients. Few people want a long to-do list they didn’t come up with.
Software developers love to work from scratch. They typically want to build a new app, not improve an old one. It’s much more fun to design a new system, with as few unnecessary restrictions as possible, and to design every bit of it on your own. Working on other people’s code is less fun, often difficult, and risky. It’s also much harder to predict the complexity, cost and issues arising from working on other people’s code.
I’m not advocating abandoning working solutions and replacing them with a new thing every time. It can also be a bad decision to abandon old code just because “new code will be better”. It won’t be better, it’ll just be different. The reality though is that a typical software team will prefer to start fresh!
A reasonable response to this question is either “no, we want you to build it from scratch” or “yes, please have a look at it and tell us what you think – can you improve it, extend it? Or will it be cheaper/better to rewrite it? Why?”
A bad response would be “yes, we already have some code, built by another 3rd party supplier; we want you to extend it, but we won’t show you the code (just yet)”. It’s unreasonable because it’ll be hard for an engineering team to plan or even imagine the work they need to do without access to the code. You want an estimate and a plan from the IT company, but they won’t be able to create it if you don’t show them what they are supposed to work with. Same features/challenges will have different solutions and cost depending on what’s already in place.
You may care little about technology, but it means everything to the IT company. First, they will have a set of individuals or teams, each capable of using a number of technologies - programming languages, frameworks, development methodologies. If you want an app written in PHP, and the company likes Python, Go and Java (like us), let’s not waste everybody’s time.
The key question here is “why?”. You may have 3 other systems you run in your business created in PHP. You may also have a team who works with PHP. In that case, it makes sense for you to build software the rest of your current team can maintain after an external partner built it. But perhaps some components or applications are separate enough to be built in an unrelated technology?
Or maybe you want a particular programming language because the ecosystem of apps/tools with which your system will have to integrate is centred around a particular language, and it’ll be also easy for you to hire people with that skill set. That’s fine, too!
However, if you are only starting a new project and someone at your company is pushing a particular technology, but IT companies are offering different technologies, it’s shortsighted to use the local team’s preference. It’s generally best to let the software house propose a set of solutions and ask them to explain, again, why they want to use that technology - and to expect them to say at least “we know it’ll work for what you need, and we have a team that’s experienced with this tech, and this tech is popular enough to find other suppliers if we part ways”.
Few clients have the time to plan and prepare everything in advance. Few businesses still try to. One of the main tenets of agile methodologies is to build small increments of the product and give it to users ASAP to get feedback from them and inform the next steps.
Typically you begin with a vision, recruit a team, begin working, and keep adjusting until what you have is good enough to launch or scale. Yes, you can estimate the cost, the time, write down assumptions and design things in advance, but in reality, everything the agile methodologies attempt to cover is frequent adaptation.
Do a little piece of an app, release, see if it’s any good, figure out how to improve it. Repeat.
Product Owner is the highly-sought individual ideally on the client-side. PO guides the adaptation process outlined above. This means PO needs to understand and communicate the vision and must be able and willing to make thousands of small and large decisions on almost everything related to the product being built! This includes: which users to focus on, what features to build, opinions on design, influence on some technical choices (from the perspective of the business, e.g. cost, maintainability, flexibility, security).
PO thus needs to talk to many stakeholders, and needs the authority to make decisions, or at least to get a larger group to come to a consensus on major issues.
Lack of a good PO is what kills products. A good PO solves many problems before they hurt the business, preventing them from surfacing inside the development team.
So when someone asks you “Who will be the Product Owner?”, you are not expected to provide the name of the person who has all the authority and time and skill required; such person rarely exists (and is considered mythical by many). An acceptable answer early on is “we haven’t chosen a PO yet. Tell us what you need from a PO, and which parts of their responsibilities could possibly be covered by you?”. This indicates that you are ready to adapt to the style of work of the software team instead of assigning a random person who may or may not be suited for the job.
You can of course also say “Here’s Tim, your PO, who owns this product area in our company and it’s part of his departmental goal this year to get it launched”. Be aware though that the fact someone owns an area within your organization doesn’t mean they will be a good PO.
A dangerous response is “We won’t have a single person responsible for this, we want you to appoint someone.” This can work, but it will require an extraordinary individual on the IT company’s side, and they are unlikely to be as effective within your organization. They are, after all, part of a different company. Influence, politics, business background and context, these things take time to acquire and it’s best not to delegate that huge responsibility to outsiders. If you do, make sure you integrate them into your company as much as you can, and that you support them along the way.
Contact our software team now!
Overall, when approaching software development teams, it’s good to already have a concrete idea of what you want to achieve and why, a basic understanding of the environment the IT outsourcing partner will work in (technologies they will use, existing code/systems they will work with, people who will work with them), such that the software house can evaluate the setup and the business problem, and propose a solution. They will also evaluate your company as a potential partner and being clear in what you want. Helping them will help you hire the best.
In the next part, I’m sharing a few more tricky questions that are often asked by software development companies, such as:
.jpg)