This is the first part of a series of articles explaining what goes into developing products for users. This series aims to equip software engineers with the knowledge needed to execute a project from inception to launch.
Disclaimer: Everything I write, I learnt from reading and studying people who have built products as well as my personal experiences as well, (I've not built enough stuff to insert myself into certain conversations).

Now that that is out of the way.

At the heart of every project is a need, a need for something to be done to make the lives of people a little bit easier. All great ideas stem from that desire and need to make or create something that can, in one way or another, impact the lives of people, negatively or positively, hopefully, we're all building to make the world a better place.
The owner of the idea here is your customer, a customer can mean directly interfacing with an actual 'customer', your engineering manager, your project manager, or anyone you are accountable to as regards the actualization of bringing the idea to real life and pleasing them should be the priority of the project.

There are two major concerns that every customer has, Cost and Time. They are interested in how many resources will need to be allocated to development over how long, it is advised to build within the stipulated time using the allocated resources, but how do we do this? Well, one way not to do this is to employ what is referred to as "Big Bang Development", this is when developers crank out code and do not get any feedback from the customer until the deadline is in view and more often than not the customer is never thrilled with the delivered results, and the title of this article states, pleasing your customer. So, How do you please your customer? How do you know what the customer wants?

Software development is many things but one thing it is not is guess-work, it is so so important to the success of every project that customers are kept in the loop with whatever is being built. When in doubt, ask questions, when things feel clear, ask questions, why? because it is difficult for customers to know what they want at the beginning of a project and your questions are what inadvertently guides your customers' decision-making on the route your project takes. Always ask questions.

Great software development delivers what is needed on time and within budget. I really cannot overemphasize the importance of this, sticking to the set time of delivery is very very important. Again how can you achieve this?

Iteration.

Iteration means whenever significant progress is made, you check back with your customer and refine what you are doing to align with their vision, it is like a frequent checkup for your software, you'll always know you're on the right path. With iteration, you also do not make any major decision without involving the customer, it just keeps everyone happy and sane.

One question in your mind, can't you just spend more time getting to know what the customer wants, like you get all the requirements down from day one and carry on with development?
Now the problem with this, the customer more times than not is also still trying to figure out what the project really is and what can be achieved with the product, and they, more than they like to admit, hope that the development can chart a path in their mind on the very many ways the product can be built. You need to help the understanding of the team as well as your customer about the software being built, you cannot do that if you have all the requirement dotted down from day one, and speaking from very personal experiences, it is a disaster waiting to happen I tell you.

Hope the question is answered. if not reach out to me on Twitter, and let's talk.

So back to iteration, as we already established, the "big bang approach" to software development usually ends in tears, the end product of each iteration is to produce working software, working software can mean several things, from a functional button to a modal or say a full web page, all depends on the conversations between you and your customer.

Each iteration is a mini project, you take the steps you'd follow in building the entire project and use them in each iteration. Each iteration has its own requirements, design, tests, code etc, so we are not releasing junk but pieces of the final software.

Your iteration length must be the right tempo for your project, You don't want to be controlled by a tool and lose sight of the main goal. You should iterate enough to catch yourself deviating from the original requirements.

Remember customers are also learning alongside you while you are building, what if the customer learns of more functionality that the software can cater to, how do you handle this? remember you are on a clock and a budget.
It is up to us as engineers to make the necessary changes. Iteration handles that for us. We can follow the following steps to help us navigate these stormy waters

1. Estimate the new features, and figure out the time needed to build them.

2. Use order of priority, and assign a priority value to each feature to know which is the most important and needs the most attention.

3. Rework your iteration plan and fix the most important features in the right place on your feature board.

4. Check with the project deadline.

When it comes down to this, we might not be able to account for all the features within the stipulated time, you need to have hard conversations with the customer and allow them to decide what features stay and which features leaves.

In Conclusion, The happiness of a customer and the timely delivery of the software is the most important thing in building out products.

I hope you were able to learn a couple of things from this article, like I stated earlier, this is a multi-part series and I'll be writing on other topics on the software development lifecycle in due time.

Until next time! Cheers!