15 Questions to Ask at the Start of a New Software Project

When starting a new software project, there are a series of questions that need to be explored before diving headfirst into the development cycle. At Atomic, we often spend time in what we call the “ Research, Design, and Planning ” phase of the project to do just that.

During this phase, we’ll seek to better understand the product, business, users, and overall project journey that we’re about to embark on.

Below I’ve outlined the core questions I target at the start of a new software project.

Product Discovery

What problem are we trying to solve? Why?

Custom software is not cheap. Be sure to evaluate why your customer is looking to dive into it in the first place. Create space for all stakeholders to respond, as there are likely many different perspectives behind “the why.”

Is there a similar product on the market? If so, how will we differentiate from it?

Benchmarking what other products exist is a great exercise to do during a Research, Design, and Planning phase. Use this time to understand how this product will be different. What value is it adding that others are lacking?

Are there other products or tools that we can, should, or need to integrate with?

Does the product include a wearable device? Does it need to tie into other internal or external systems? Integrations will shape both the design and development approach, so knowing about them from the get-go is ideal.

Business Discovery

What value are we providing to our business?

Will the product help with sales? Will it provide impactful data? What is the reason our business is seeking to create the software?

What does success look like, and how will we measure it?

Understanding expectations is crucial. Work with your team to create a shared understanding of what success is and how you might measure it.

What business risks or blockers exist?

For example, is there a crucial integration that we need to work with IT on, but IT is booked out for 6 months? Is there a stakeholder who has the true vision of the product, but they’ll be on leave at the start of the project?

Who are the key stakeholders, and what kind of access will we have to them?

Use this time to map out who your stakeholders are and set expectations for how engaged you will need them to be. How might you ensure the project never gets blocked from a lack of stakeholder feedback?

User Discovery

Who will use the product?

At the end of the day, we’re building the software for people. Who are those people? What are their goals, motivations, and frustrations?

What value are we providing to users?

Why would folks be inclined to use the tool we’re creating? Understanding how we are providing value to users will help us determine which features to include and how to prioritize them.

What risks exist if a poor-intentioned user has access to the product?

Though we’d love to assume only well-intentioned people will use our software, the reality is that this may not be true. What kind of trouble could occur if avillainous persona gets their hands on our software? Determine what the risks are so we can design to mitigate them.

Will we have access to users for research and testing?

Having access to users is crucial for validating the overall product and workflows we create. Be sure to begin the process of locating and scheduling time with users as soon as you can.

Project Discovery

What key dates exist?

Is there an event where someone hopes to demo the software? Is the software itself tied to a specific time of year? It’s important to know if there are date-sensitive deliverables to ensure on-time delivery is achieved.

What are the expected deliverables?

The detailed scope of the project will shape over time, but at the start of a project, high-level deliverables should be determined. Is it a mobile app? Is it an API? Does part of the project include training and onboarding the customer’s developers once the product is ready to hand off?

Who is the primary decision maker?

At the end of the day, who gets to make the final decisions? This ideally should be one person, in order to avoid a decision paralysis or design by committee.

How might we best work together?

What are the communication preferences across the team? Will you be working on-site together, or remotely? How often and to what capacity can and will your stakeholders be involved? Set the cadence for the project. I recommend setting up recurring calendar events early on, well—before calendars get full and you become blocked on stakeholder feedback.

You Can’t Know Everything Up Front

It’s likely you won’t be able to answer all these questions after just one workshop. It will take some time working with your stakeholders and interviewing users to shape what the product will be. However, these questions should get the ball rolling!

If you’re interested in how to go about extracting this information, I recommend checking out our Design Thinking Toolkit .