10 Things Startup Founders Should Know Before Working With Software Developers
Bringing on your first software developer is a huge milestone for any early-stage startup. At this point, you and your co-founders have put countless hours into your business idea and feel ready to start building the first version of your product. However, founders sometimes start looking for developers before they are ready.
We want to preface that there are still a lot of risks even after you build your product, but there are steps you can take to set yourself and your business up for success. In this blog, we'll walk through a general overview of the steps you should complete in your startup journey before hiring a developer.
We will also provide a checklist of questions that you should be comfortable answering before looking for a developer.
Risks of Not Being Prepared
Finding the right developer is hard. It entails investing a lot of time and money. You really only get one shot to choose the right person because of it. With that in mind, it's essential to organize and aggregate your goals and objectives before vetting and selecting the developers you'll work with.
Since there are many types of software developers with different backgrounds and specializations, it's your job as a product owner to have a crystal clear picture of what you are trying to accomplish. You also will need to figure out whether you want to hire the developer to be in-house or to outsource them from somewhere else.
Usually, as long as you are upfront about what you need, reputable developers will have a good idea of whether or not they can provide what you are looking for. As always, be sure to do your own due diligence.
If you don't have a technical co-founder on your team, this prospective developer will significantly impact your company. They will help you choose critical components that make up the foundation for your entire product. Once made, these foundational decisions are incredibly difficult or expensive to change.
All you can do to mitigate these risks is to have a solid idea of what you are hoping to achieve and communicate those needs to the prospective developers. This will help the developer figure out what they need to do and whether or not they can do it, given the nature of the product and the overall project scope. Ultimately, they will decide to see if they can help you get to your goals at the price point you offer.
10 Things to Keep in Mind Before Hiring Software Developers
Developers don't expect founders to know everything about software development, but in order to do their jobs, they need to know basic facts about what you want the new product to do. As you progress through the customer discovery and product design phases, your team will naturally create artifacts that will answer these questions for you.
In line with that, it's best to keep these aspects in mind right from the onset of your product conceptualization efforts, so it'll be easier to convey your goals and objectives to the software development team once they're onboard:
Customer Discovery: Laying The Foundations For Your Product
The first phase of the product development lifecycle is customer discovery. Customer discovery is the process of speaking with potential users in your company's space to better understand their problems and pain points.
Your business idea might have come from your personal experience in the industry, but it's always a good idea to validate that other folks are experiencing the same or similar issue and that there aren't existing solutions that already address the issue in the same way.
In other words, customer discovery attempts to validate the business idea before you decide to go all in with product development and go to market. The goal of this phase is to understand the current user experience (UX) and hopefully create a great product that will improve that experience.
During this phase you will answer the following questions:
The answers to these questions will inform you about the product's intended purpose and its critical features. If you don't have a clear picture of who your intended users are, you run the risk of every company's nightmare – building something that isn't useful to anyone.
There are 3 core artifacts that are produced in this phase that will help your prospective developer understand who they are building the product for:
1. Problem Statement: Know What Your Product is For
The Problem Statement is an articulation of the problem you and your company are trying to solve. Writing a compelling problem statement helps others understand what the company is all about and is a powerful way to align stakeholders.
It also forces you to think about the industry you are currently in and the problems and gaps that are prevalent in that space and point you in the right direction for potential user interviews. Whatever you end up creating will attempt to solve this problem.
For example, UberEATS pegs their problem statement as "UberEATS is on a mission to make eating well effortless for everyone, everywhere." Here, you can see that UberEATS identifies the problem people have of finding time to have healthy meals amid their busy schedules.
In using a problem statement that also provides a solution (make eating well effortless for everyone), they are able to center their services on achieving that goal through the services provided on their app. It's not just about making sure their customers eat, but making it EFFORTLESS for them to eat HEALTHY.
2. User Personas: Know Who Will Use Your Product
As you conduct interviews with potential customers and get to understand their pain points, you will want to synthesize all of the information from individual interviews into 1-2 user personas. A persona is a characterization or archetype of your company's use cases.
Different types of customers will have unique problems that will change the way they will use your product. The point of creating personas is to identify patterns across different demographics and tease out underlying needs across groups of similar people.
You will also want to think about the assumptions you have about those personas and how you might validate or disprove those assumptions. Knowing your target audience is essential for the software development process. Personas will help you prioritize core features and plan user stories. Additionally, identifying personas will help you market your product and acquire your first users down the road.
3. Proof of Concept: Know if Your Product Adds Value
Before you hire a developer, it is important to establish proof of concept. Proof of concept is a prototype or early version of a product that demonstrates the feasibility of the product's basic concepts and functionality.
It is a preliminary step in the product development process that allows a team to determine whether their idea is worth pursuing further. Creating a proof of concept can help identify technical difficulties, risks, and potential solutions.
Your proof of concept will answer, "Do people actually want to buy your product, and is it going to be useful?." When you factor in how much time, money, and effort will need to be spent on developing this project, you have to make sure that there is a market for this thing you are creating.
You want to make sure that you don't jump head-first into a project without seeing if there is a future for it and if it serves a purpose. As a founder, you will put your heart and soul into this project, and it would be crushing if the product is dead on arrival because customers don't want or need it.
To avoid this, you need to gather customer feedback. Ask the users you talked to in the previous steps to give you feedback on your idea(s). Check-in with them and see how they react! Your goal is to uncover the answer to, "What would they want to change in order for them to use your solution over what they are getting by with now?"
You might be thinking, "how do I test this if I don't have a product yet?" but it's not necessary to have a product at this point. What is necessary is that you understand the problem your users face and how your product directly solves or addresses that problem.
Design and Prototyping: Start Creating Your Product
Now that you have a clear idea of the problem you are trying to solve and who you are trying to solve for, the next step is to design your solution to the problem defined by the problem statement – your product.
For now, we are going to assume that you have a pretty well-thought-out product idea that has been run by at least a couple of folks in your network. The next step in the product development cycle is to come up with initial features in the design phase.
4. Determine Your Product's Initial MVP Features
Even if you don't have a developer on your team yet, you and your team should spend some time determining the initial features of the minimum viable product, or MVP. The Minimum Viable Product (MVP) is the v.0 of your product that has the minimum features required to do the basic thing it's supposed to do while still being a product that users can interact with and give feedback on.
This is actually the toughest part because everything tends to feel important enough to include in this first version. However, the MVP is supposed to be the bare minimum. Assuming you currently have a running list of features you want to include, your first priority is to figure out the expected inputs and basic navigation.
From there, you should focus on developing low-fidelity mockups and user stories. If you get positive feedback on the MVP from an unbiased sample of users, you have a significantly better chance of having a successful product launch.
5. Outline the Expected Inputs and Basic Navigation
When it comes to outlining the expected inputs and basic navigation of your product, you need to think about how a user will interact with your product.
These are all important questions that developers will ask you, and it's best to have at least a rough idea of these things before you meet with them. If you are having trouble with this step, it might be helpful to talk with a design consultant.
6. Create Low Fidelity Mockups
The natural progression after would be to create a low-fidelity prototype that encapsulates the decisions you made in the previous step and think about the user interface (UI). You should work towards having a basic understanding of design tools like Figma, but if you don't have the capacity to learn a tool at the moment, you can still work on a pad of paper.
Making a wireframe of your product on paper will help developers understand the basic layout of the app and how you want your users to navigate through it. Play around with different layouts and see what you like and don't like. With that, you'll have the chance to uncover the following:
7. Understand Your User Stories
The next step would be to think about the user story. User stories are non-technical descriptions of each feature that you give to a developer in order to communicate the intended purpose of a particular feature from the perspective of an end user.
This is the end goal and will be used later in QA in order to check that the feature was executed correctly. You should also think about how features will come together and accomplish the product's purpose for specific users. User stories will help you figure out dependencies and show that you know how the big picture comes together.
Developing a strong user story upfront will save a lot of hassle at the end of the project because it would clearly lay out all of the expectations of the app. You want it to be relatively clear-cut whether the developer was able to deliver or not. Doing this exercise can also help you decide which features are actually not as important to the product.
Scoping: Set Your Goals and Expectations
Another thing developers would want to know is the scope of the project. Scoping is the process of setting expectations for the project. Scoping will help you avoid setting unrealistic goals and expectations and establish best practices for effective communication.
8. Deliverables and Quality
Deliverables are artifacts that a developer will give to you at an agreed-upon time. During the consultation, developers will want to understand what you want from them and when. You need to establish your priorities – do you want to prioritize speed, quality, or budget? Even under ideal circumstances, you will only be able to have two of the three priorities. This concept is called the Iron Triangle of Product Development.
All of these factors will contribute to how much your project will cost. Always keep in mind these considerations when outlining the pace of deliverables and the expected quality you are after. Otherwise, you run into issues of scope creep, which ultimately derails and delays development projects.
9. Product Roadmap and Project Management
Another thing a developer will ask you for is a general project roadmap. Giving them a map when you want to complete major milestones will be super helpful. They will give you feedback about what is and isn't possible. You need to be open to adjustments or compromises on quality or budget.
Additionally, you might want to consider having a product manager or project manager (PM) on the team in addition to a developer. If you work with an agency, you might be able to hire a PM part-time in addition to a developer.
The PM's job is to coordinate the engineering team's workflows and facilitate cross-functional communication with technical and non-technical team members. A seasoned project manager will be able to put together budget estimations and reports, which can give leadership a high-level overview of what's going on with the project.
A common project management methodology is Agile. The Agile Methodology focuses on completing tasks efficiently and iteratively, which allows teams to adapt to ever-changing circumstances. With Agile, the team has an easier time deciding whether the developer needs to pivot or if the team can dedicate more resources towards fixing that particular issue.
10. Role Expectations
It will also be important to think about responsibilities, communication, and management styles. Everyone works a little bit differently, so it is always a good idea to ask prospective workers how they like to be managed and make sure it aligns with your management style. Here is a list of questions you should ask yourself to help you decide whether a candidate is a good fit for your company culture and your management style:
Next Steps
Altogether, if you have done everything so far, we want to give you a sincere round of applause -- as a startup founder, you are responsible for wearing a lot of hats, and you have done so much work. But, as they say, the grind never stops, and there are so many things left to do. Here is a list of questions to help you start thinking about the future beyond developing the MVP:
Bottom Line
There are quite a few things to do before getting started with a developer. You need to have completed customer discovery and started low-fidelity prototyping to know who your users are and what your product will bring to the table. You also need to have figured out the project scope and accounted for the time and money needed to find this person.
Especially because you are looking for your first developer, the decisions they make will determine a lot of the future of your company. If you aren't prepared and give them inaccurate information, there is a high chance that there will be fires down the road.
Also, it is important to practice empathy and think about the project from a prospective developer's point of view. Would I want to work for someone who I feel isn't prepared? The developer isn't going to expect you to have everything figured out to a T, but having a general understanding of what you want the end product to look like gives them a better picture of what they need to do.
