So you’re ready to break into the wonderful world of software products; Welcome! We have cookies, just probably not the kind you’d expect…

We know how daunting choosing a development team can be and it becomes even more challenging approaching from a non-technical background. Not to fear! We have got you covered.

Software development for non-developers

You don’t need to understand the ins and outs of several coding languages to be able to effectively select a development team. All it takes is a basic understanding of how software products are created by the people building them that matters.

Sprints

Software products are built in chunks. One week chunks, to be specific.

In Agile software development, we call these chunks “sprints”.

Sprints are a far more manageable way of developing software products over the development marathons that occur when attempting to develop products in one fell sweep.

Building in sprint-like increments grants you access to time and money that would have been lost had your team had to backtrack or alter the plan several months in.

It also helps ease the pain your development team feels watching a developed feature be thrown out.

The highest value item is what your development team works on during their first sprint.

High-value items are features that provide your product with the highest value for the function. Such as a shopping cart for an online marketplace or a calendar booking app for a therapy-matching website. The highest value item then is the feature that does the absolute most for your product overall.

Your sprint should include a test day on the final day of the five-day cycle.

How will you know if it’s a success or a failure? Try your best to put some quantifiable metrics against your testing so that it is clear if the feature is something you should continue to pursue.

To determine what gets worked on during each following sprint (dependant on the results of your testing), ask yourself what is the next highest value item that we could provide or what could we put in front of a customer that will test the business model?

Be disciplined! Quell your urge to keep adding more features until the one(s) your team has built are verified by the customer. Removing as much scope as possible will help you build what is only of value.

At the end of each sprint, something needs to be delivered for the product as a whole. Whether that be a fully functional feature or a change in plan or adjustment to the feature, never walk away from a sprint empty-handed.

Things to Remember

You will build features that will be wrong

We all make the wrong call sometimes. Even though we might think we know what’s best for the user, our assumptions can easily be flipped on their heads come test day.

Thankfully, this is why the sprints work so well in terms of scope management. The plans laid are easy to pivot on while keeping any costs incurred to a minimum.

Don’t be afraid to throw stuff away

Holding on to features or code that fail to serve a purpose will hinder your team’s progress significantly.

As discussed in our blog post, how your software development team can build an MVP, products developed via a lean development mentality serve to effectively fulfill the needs of the user while saving the client’s time and money by avoiding the development of apps or features that do not end up being used.

You will learn things as you go

You now at least have a basic understanding of the software product development process which will aid you greatly when you work with your development team. However, you can’t expect yourself to learn everything there is to do with software development overnight.

Your knowledge will continue to grow and expand as you and your development team work together to build the product. Remind yourself of this in cases where you don’t yet know something.

Picking a development team - five questions you need to ask

1. What experience do you have working with startups?

Building products from scratch is a very different process than working with products that already exist.

You are going to want a team that understands, at the very least, the fundamentals of start-up dynamics. It’s better yet, to find a team where the lead is well-versed in the way of the startup.

They’ll know what to expect in terms of workflow and expectations, know how to communicate progress to you, and know what needs to get done in order to get your product launched in an orderly fashion.

This grants you the time you need to attend to the many other tasks that come with the launch of a new product.

2. Is there a project manager or business analyst on the team that will help me understand my product and build a development plan?

The technical project manager will be your go-to person for any and all questions you may have regarding your product and development plan.

If there is no business analyst or project manager on the team it will be on you to either a} find, hire, or contract one out or b) manage these tasks yourself.

This is why this question is important to ask. It lets you know what is expected of you regarding this endeavour and whether you need to be talking to someone about managing this task.

3. How often will I be able to view progress?

A solid development team is going to have a staging server that you can monitor progress from at least once a week.

This server is a completely separate platform from the “production environment; the server that your real-world users interact with.

This is important as it allows you to monitor the progress of your product and experiment with functionality without impacting real users.

4. What technologies do you think we should use, and why?

Each team is going to have a set of technologies that they are comfortable with.

Check that their choices meet your needs in terms of how quickly they can build with it (which you will see if you insist on weekly turnarounds), how much it will cost to host (discussed below), and how easy it is to maintain (how often does this framework change? how often are we going to have to do upgrades?).

You want to know that the team your hiring for your cause can not only work quickly but can work in line with your product and business values (a concept we dive into more deeply in our How to Build an MVP post).

5. Security

A single data breach can spell the end of a company, so the security of your product needs to be considered first and foremost.

Ask the team:

How will my customer information be stored?

What information needs to be encrypted?

Are we ensuring that data is encrypted in transit?

What are my monthly costs for server hosting?

How will this go up as I scale?

How does the technology you’ve chosen for my product ensure its security?

If they don’t have sufficient answers to these questions, they may not be the right team for the job.

If you weren’t 100% clear on some of the concepts, technology, or programs that they provided you with for these answers, take some time that evening and look into them. It never hurts to do some research.

Additionally, if something doesn’t feel right, let your potential development team know. They are meant to be a partner in your development journey, not an all-powerful ruler. The right team for you will be more than happy to listen and address your concerns.

Final Thoughts

Software development is not a linear process

Software development is a rather non-linear endeavour.

Changes to the plan are sudden and development often occurs in different directions simultaneously.

As a result of software’s ever-evolving dynamism, the act of planning as you go, and making changes to that plan swiftly when needed is how you create a product that truly fulfills a need.

Non-linear processes do not come without their challenges.

You have to be quick, agile, open-minded, and above all, confident that you and your newly appointed development team can solve your way out of any problems that present themselves.

So if a feature that you loved originally doesn’t fit into the product plan or users come back telling you that the product has issues, do not be alarmed.

This is all part of the non-linear process for developing great software.

The “final” product might not look like what you originally planned

As mentioned before, software products witness a lot of change.

Founders often realize that additional or different features could prove better for the user as the project progresses and grows into its “final” form.

The end product may not always look like what had originally been envisioned as a result of these changes.

Try to keep an open mind when this happens. If you’ve hired the right team, you can trust that these changes are being made in the name of the user of your product and your business goals.

There might not be a “final product”

When building a building, the plans that are laid out in the beginning generally do not witness much (if any) change. The building is constructed in systemized and enduring steps that were decided upon at the beginning of the project.

As we know by now, software products often grow and evolve as they progress.

As a result, the vision being worked towards is almost always done so with preparedness for change that occurs as the project develops.

Software products have no true “end” to their development. They can be added to, built upon, and altered to lengthen the product’s lifecycle infinitely.

It pays to keep this in mind when constructing your development plan. Additional features can be added at a later date. It doesn’t all have to happen at once.