Have you ever gone into a software development company, presented an idea, and asked, “how much will it cost” or “when will it be done”? If so, you are not alone.

Were you surprised to hear the response or did you sense the vibes and blank stares from the Lead Developer or Technical Sales person as they contemplate your questions? Did they say, “I don’t know” and get up to walk out? Did they look disinterested? Did they make some knee jerk estimation that was outrageous? Did you walk away from your inquiry with confidence in knowing you have the right people on your bus and in the right seat? If this is a scenario that describes your past experience, then that is not uncommon, and quite frankly, it's sad. The question you should have asked them is, “are you able to identify my specific needs and problem solve in order to develop my custom software?” If you didn’t ask that and want to know how that relates to dollars and scents, then keep reading. Hopefully you will gain value in looking back on your experience with new insight. Maybe you have thoughts that you wish to share after reading this article. Maybe the scenario I described ignites a fear to move forward with your new idea? If so, then this article will help you understand how you can become an informed buyer of custom software.

Know this first: not all custom software development companies are created equal. Some companies may have devs on their team with a ton of experience or with little experience. Some may have devs with competency in multiple tech stacks (layers of elements required to run a website, program, or mobile app, etc.) or only one tech stack. Some companies may have exactly what you are looking for by providing a team like environment that is willing to collaborate and go on your journey alongside you.

Some companies may implement an Agile Development process for making custom software and some may not- tisk, tisk.

What you should know first and foremost is: How the Soup is Made

The Five D's of software development. They are Discover, Define, Design, Develop, and Deploy. Understanding these pillars, or phases, will help you be a better Product Owner. Each phase incurs costs. Each phase has goals, risks, and deliverables. Each phase in and of itself can be a place where great ideas die on the vine or new discoveries are revealed propelling a nascent project to great success! It is hard to know what to expect of the dev team and your role as the Product Owner if you have never heard of The Five D’s. Ultimately, at the end of the day you are a Product Owner. So you should own the process and understand The Five D’s.

Below is a short description of each phase.

• Discover - work as a team to ideate, create goals, and draft an MVP (Minimum Viable Product)
• Define - identify and quantify the problems and plan the attack with a solid MVP
• Design - visualize and architect the solution and process feedback
• Develop - implement the solution and achieve objectives
• Deploy - deliver the developed solution

Lather, rinse, repeat, as you will certainly go through this lifecycle multiple times, or at least you should if you have the right type of dev team on board. Knowing this process can equip you with the understanding of the right questions to ask at the right time. You are now an enlightened buyer of custom software.

Within The Five D’s comes The Churn

If your dev team of choice practices The Five D’s, then the next point you need to understand is the inevitable amount of churn, or changes, to expect when developing custom software. Here it is, defined by Google. Let’s combine a few of those phrases (assuming you clicked the link). Let’s mix, “to agitate or turn” with “encourage frequent turnover”. Your role and the role of the development team should welcome changes and be willing to agitate each other to ensure best results. Antifragile much? Heard of “Iron sharpens iron”, right? A small grain of sand can create a beautiful pearl, right?

“Discomfort is a desired state”.

If both you, the Product Owner, and the dev team, can adopt the process and standardize the way you engage, then you, your project, and your customers will benefit. Frequent collaboration and feedback loops sets the expectation that change is a constant. If you and your dev team are not communicating daily, validating ideas, entertaining questions and concerns, and willing to iterate in all phases, you may have a big risk to the project’s ability to succeed. Some Product Owners, like yourself, are either extremely hands-off or extremely hands-on. If you plan to be hands-off, then be ready to own the result. It may not be in your favor. So understand that change, change is gonna to come. Best embrace The Churn and be an enlightened and engaged buyer of custom software.

From within The Churn comes the Rigor

“People over process” is the one of the 12 Agile Principles, but developing technical rigor through good daily and weekly habits within all of the phases are important. The saying goes, “you can’t manage what you fail to measure”. However, it doesn’t have to be so rigid that your project starts to stink of its dogma. SMAC Lists (specific, methodical, and consistent) are not evil, just check them at the door so as to not fall in a comfortable trap. If your dev team has these qualities and principles then you should be confident when a change is introduced that it will be handled appropriately, in the right way, by the right people. Being on the same page might be cliche, however, if you are pragmatic and stick to a consistent and adopted practice that helps you and the dev team, then consider it protecting your investment. You are now becoming an enlightened, engaged, and disciplined buyer of custom software.

From the Rigor comes the Validation

If you have never developed custom software then you can’t relate to what you are about to read. Spending money and time on testing is important. When you are finding bugs with custom software, as the Product Owner, you enter into a realm of reputational risk. Ask yourself, “is there an amount of money I would give to improve my reputation or mitigate my reputational risk?” How much would you spend?

Well, regardless of what that number is, if your dev team doesn’t believe in testing often and gathering feedback from your end users, then you will get what you pay for. It might be expensive and drive up the costs, but once you have been bitten by a bug it is very difficult to put the broken eggs back in the carton. If you spent 40% or more of the entire scope of work in the Discover and Design phases of your project, then according to Google, your project is the norm for "successful" projects. Consider testing validation for the time spent planning. As the Source of Truth, aka the Product Owner, you need to evaluate the value you are being provided by your dev team in every phase. Did your team assist you in going down the correct path? Did they prevent falling into pitfalls and avoiding landmines? Are they able to validate the planning in the first hour of the project that will inevitably save valuable time when it is most crucial- prior to launch? Now you are becoming an enlightened, engaged, disciplined, and validated buyer of custom software.

From Validation to Measurement

You can’t drive a car forward on the highway by looking in the rear view mirror. The same is true for software development except you don’t have a mirror. Knowing how much time a feature took to develop or how much money was spent over the course of a Sprint will help you answer your first questions, remember those? But instead of wishy-washy logic or potentially selfish reasoning you will stand on empirical information.

What informed decisions did you make that helped shape your project and assist your team during development? What assumptions did you have that were challenged or wrong? Which assumptions were validated? When did you feel uninformed and unsupported? When did your dev team feel uninformed and unsupported? How did you overcome challenges during the process? How often did you communicate the challenges? How much time did you spend in each phase as a result looking over the details? What did you look over to prevent missing critical information, or was it overlooked? Does the latest iteration of the software perform based on your current understanding and expectations? What did you observe that affected your experience?

You are able to see the consequences of your decisions based on your experience. You are now an enlightened, engaged, disciplined, validated, and empirical buyer of custom software.

By now you hopefully have some idea that being involved and becoming a part of the process is important when buying custom software. This understanding helps define what it is you and your dev team are building together, not just the “guestiment” or some imaginary timeline that is no more than a transaction. You might feel empowered and discover a piece of the puzzle that was missing all along, a relationship. Instead of asking, “how much” and “when will it be ready”, you might ask “what is it we are building and how can I be a part of the solution?” If you proposed those questions to the devs at the software company down the street, they might fall over in their chair or ask to buy your lunch.

Do you feel informed by this article? Would you consider yourself an informed buyer of custom software now that you have read it?

Provided below is a glossary of some terms used in the article.

Glossary

Agile Development - An alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, continuous testing and continuous integration.

MVP - (Minimum Viable Product) In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk.

Scrum - An agile software development model based on multiple small teams working in an intensive and interdependent manner.

Source of Truth - The person designated and authorized by the Product Owner as the ultimate decision maker as to product elements, functionality, and content.

Sprint - In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration.

Story - A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

Task - An essential element in the completion of the development of a Story.