How to build software products with purpose?

There are more and more,

we can see how the project managers and teams get lost with the different methodologies when they hit the trenches.

Methodologies are just a set of processes to facilitate product development. Each of them takes a stand from one or two sides and try to stimulate some of the things you can see below.

The key important things for good software development are;

  • Purpose
  • Progress
  • Alignment of expectations
  • Communication
  • Integrity

Methodologies from the top divide into two. (There are many ways to divide it)

Structured and Agile

  •  Structured 
    • Iterative: A structured technique whereby developers first create the most basic form of the product, complete testing, and then go through constant cycles/iterations to add additional features, testing after each iteration.
    • Spiral: A structured, iterative approach that continues to spiral outward (get bigger) while going through four distinct structured phases (determine objectives, risk assessment, develop, then test, and plan the next iteration).
    • Rapid Application Development (RAD): A structured approach to create user requirements and final design, but one that focuses on prototyping in lieu of functional planning. The constant prototyping allows for trial and error of functional requirements.
  • Agile
    • In 2001, a group of programmers decided there was a different way to develop software and published the “Agile Manifesto.” Agile emphasizes collaborative development by smaller teams comprised of clients, developers and other experts, followed closely by review and adaptation. This “develop-review-adapt” cycle continues as the teams produce rapid iterations of a product until it is completed.
    • 31e18156b678a321e41b719f7f480742

There are more details and you can find great articles explaining all of them, I recommend starting from Wikipedia.

Let’s just focus on Agile methodologies for now.

The agile manifesto says:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Let’s take some examples of agile development and compare it to some of the important things, I have listed earlier.

SCRUM: Scrum process is mainly focused on interactions. Stand up, Review meetings, retrospectives, dedicated person to remove impediments (scrum master), and representatives of the customer (Product owner). The best part of scrum is retrospectives, if they are done correctly, unfortunately, Stand-ups often becomes reporting sessions.

“This what I have done yesterday, this is what I am going to do today”.

If someone has not managed to do what they said, then group pressure mechanics start playing. The other thing, you can also see and unfortunately, I have not had any real good answer is; Majority of programmers are introverts and we expect them to explain themselves very well in front of a very intelligent group. You could see programmers, solving really complicated problems and fail to communicate it importances of that same problem. Then an extravert comes in and explain a simple thing as he founds the cure for cancer. This is really annoying for developers. When they complain about scrum, they mostly complain about other things than communication problems because the other one is a little embarrassing to say loud.

XP tries to answer the agile manifesto by introducing process by computer engineering best practices.


And there are several other methods, like Kanban focus on efficient workflow, remove waste. Feature-driven development focus on working software and vertical slices.


Where to start?

Give your team A PURPOSE, tell them why we are doing what we are doing. Start everything with WHY.

You should start from the top and support it from the bottom.

This is an explanation of “company “from Wikipedia.

Company members share a common purpose and unite in order to focus their various talents and organize their collectively available skills or resources to achieve specific, declared goals.”

Then, you see many companies where employees have no clue about the purpose.

The mission of the company should be a specific and a declared goal. We call this a Level 1 goal, and this goal should be a S.M.A.R.T goal.

  • Specific – target a specific area for improvement.
  • Measurable – quantify or at least suggest an indicator of progress.
  • Assignable – specify who will do it.
  • Realistic – state what results can realistically be achieved, given available resources.
  • Time-related – specify when the result(s) can be achieved.

Don’t get lost between mission and vision. Vision is the place we would like to go and the mission is the way to get there.

The level 1 goal should be unified for the company and even for all its departments. It could be 3 months to 1 year. And later all departments should define their Level 2 smart goals that support Level 1 goals.

Screen Shot 2015-08-20 at 21.47.07

 As you can see Leve1 goal is divided into level2 goals and those goals are shared between marketing (M) and product development (P)

Once you are done with Level 2 goals, you need to get together within departments and start breaking down even further to level3 goals and start aligning, who should do what and when. Each goal should be a s.m.a.r.t goal. When you hit the team level this becomes the epics or features depends on the methodology you choose.

Let’s move on to the 2nd most important thing.


Things in motion create their own dynamics.

Do you remember the first law of Newton?

“Things in motion tend to stay in motion”

Imagine how difficult sometimes to start something new and once you start it, it just rolls and rolls. It is very important to show a sense of progress.

Moving post-its around, from backlog to done on whiteboards. Using software to show the burndown-chart. Digital Dashboards. Having a bell and ring it whenever a feature is done, etc and etc.

Take a decision and move and show that you are moving to everybody.


Alignment of expectations 

When you are working with Goals, there is no such thing as plans. Plans are replaced by Road Maps.

Imagine you are leaving home to go to work. The purpose is to get to work at 09:00. You left home, you realize that your car tires are flat. Now you can either change the tire or decide to take the bus or the bike. You decide to take the bike, you take your bike out of the garage but it starts raining. You leave the bike, run to the bus stop, but you realize you are getting late for your meeting, then you stop a taxi and barely make it to work on time. On the way, you can also call the work and try to reschedule the meeting. Every project starts with unknowns and on the road, you get smarter and you make adjustments.

When you are working with goals you need to inform the other departments, especially the goals that you share with other departments or teams. Their work will be affected by the changes, so it is very critical to align expectations at any time. When teams work with plans. They wait and try to use all the time to deliver what is expected and when they don’t make the deadline, it is too late for the other department to align with their plans.


You can’t just call for meetings all to the time to align with expectations. There are very smart ways you can do it. If you are in the group, do it on a stand-up, or just put your headphones down and make people talk, work together. Make your developers sit close together.

Think it like you are driving a car.

Your front window shows where you are going. You can do this by calling all stakeholders to kick off meetings.

Your dashboard shows the speed. You can use the digital dashboard to show the velocity, burndown charts, or whiteboards. Kanban boards.

Your rear mirror shows where have you been. You can use presentations to show the state of the product. Do it on Friday afternoon meetings, desk reviews.

Now we almost get to the end of this post, but there are still things we should talk about.

Screen Shot 2015-08-20 at 23.08.34

You will find yourself in different situations, in some cases, your team knows the technology, but not sure about the requirements or vise versa.

Two things to consider.

  • Maximize the chance of success
    • Build a great product with many features that increase the odds that customers will want it.
    • Problem: No feedback until the end, might be too late to adjust.
  • Release early, release often
    • Get as much feedback as possible, as soon as possible.
    • Problem: run around circles, chasing what customers think they want.

Create a Minimum Viable Product. (MVP)

  • The minimum set of features needed to learn from visionary early adopters.
    • Avoid building products that nobody wants.
    • Maximize the learning per money spent
    • Get the facts before it’s too late.

This can also create Fear in the team

  • False-negative:”Customer would have liked the full product, but the MVP sucks, so we abandoned the goal”.
  • Goals are complex because customers don’t know what they want.
  • Too busy to learn: “it would be faster to just build it right, all the measuring distracts from delighting customers”.

So you give a good purpose to the team and set them in motion. If they get it right, they will start executing and you will most likely witness something like this.

Screen Shot 2015-08-20 at 23.27.04

Whenever you reach a goal, give the developers some time to clean up the technical depth and fix the low-level bugs. These is just the artifacts of rapid development. If you don’t, it will slow the team in the long run.

I would like to finish with a story from Alice in Wonderland.


Pretty much you can choose any methodology for your project as soon as you understand some of the key principles of that method. I recommend going with Goal-driven development and adapting XP on the way.

Good luck with choosing the right methodology for your project.