Category: Building Software

  • Know Your Customers – Who Will Use The Solution

    Know Your Customers – Who Will Use The Solution

    One of the most common oversights in a failed product is a failure to know your customers. That may seem an obvious requirement. However, they tend to be misunderstood. We often build a solution without spending time understanding how the users will see it and their needs. It is not the same as building a solution that looks for a problem. This misstep is far more subtle. We have our customers in mind, as we should. Our failure is a lack of understanding.

    Know Your Customers And Their Pain Points

    Almost any problem can be stated in a way that leaves room for interpretation. It is challenging to avoid this. That leaves us an opportunity to solve the wrong problem or solve it in the wrong way. Think of a simple example involving transportation. A child needs to get to and from school each day. The solution could be to acquire the use of a car so they can drive back and forth. However, a child that is too young to drive will not be able to use that solution. We need requirements, constraints, and context. That requires that you know your customers and how they work. They are more than this one pain point and have multiple needs that provide context around our solution.

    Solve The Right Problem

    Another example of misunderstanding the customer is automation. We love to see automation for its strengths. It allows us to do things faster, with less room for error and less worry. However, it also can rob us of opportunities to customize a solution or learn by doing. There was a customer that had several manual processes that were done overnight. These seemed like a perfect target for automation. However, the cost to do these was low, and it provided a way to train new employees. Automation would have stolen opportunities for growth and possibly cost more than the current approach. We must look at the big picture to craft the best solution.

    Identify The Correct Customer

    One of the significant challenges in how to know your customers is identifying them in the first place. This situation is far more common in internal projects than commercial ones. Nevertheless, it can arise for any problem and solution. First, it is essential to recognize that the person signing the checks is not always the user that needs to be satisfied. That is challenging when the signer thinks they know better than the users. Yet, it must be addressed. Pleasing the wrong person or group may be the best short-term solution. However, it can be a reason for failure or lack of use over time.

    Next, the representative is not the customer. Do not be afraid to push back and hold the representative to verify statements and positions with the users. It would be best if you were confident they fully represent the users. This situation can come from miscommunication or lack of understanding. Your best way to avoid it is to ensure the team understands the goals and requirements rather than allowing assumptions to persist.

    Finally, ensure you are solving the problem for the right user. There can be competing views of a problem. An example is when workers want a job done, but owners need to afford the solution. We sometimes need to find a middle ground, but in others, we have one group to serve at the cost of another. That can be challenging to navigate and require political acumen, but failure to do so can lead to a solution that is not usable.

    How Do I Get To Know Them?

    There are many ways for us to do customer research up front and avoid misunderstandings.

    • Ask them to explain the problem and desired solution in their own words.
    • Watch them do their work and include more than just the problem to be solved.
    • Plan for regular feedback from the customer (or a representative) as the solution is built.
    • Discuss how often the task is done and why that timing is necessary.
    • Be open to workarounds and think outside of the box. The solution may be different from what is planned.
    • Be a partner with the users instead of just responding to requests.

    Signing Off On This Question

    The users are another facet of the product requirements. There should be a way to contact or communicate with them, and roles should be identified. While this often gets accomplished during a design phase, it is vital to have it from the start. That allows conversations to get started before any solution pieces get “set in stone” and can be highly useful during many early steps of software creation.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • Are There Industry Requirements Or Regulations

    Are There Industry Requirements Or Regulations

    We can have an incredible vision for a product and then fall short due to additional requirements. Industry requirements or regulations burden our solution and can even make it unviable. Likewise, these are often constraints on our solution that cannot be avoided or ignored. They might add to the cost and force the design to be done in a way that would not be our first choice. Therefore, we need to list any such requirements from the start and provide the correct context for our solution.

    Plan For Requirements Or Regulations

    One of the costly mistakes we can make is getting started on a project and then changing course. While those costs can sometimes be avoided, that is not possible if there are regulations or compliance factors for our solution. Thus, this is an area where the mistake is completely avoidable. All it takes is asking the question. Once we know the industry or corporate requirements or regulations, we can determine how they impact our solution.

    Common Compliance Requirements

    There are many ways a system can be required to be in compliance with regulations. They are not all game-changing needs. However, several common constraints are best addressed from the start. We want to ensure these detailed questions have been thoroughly answered before proceeding with our design.

    • Are there particular security constraints? This can range from complex password requirements to encryption levels and remote access. For example, that can include steps to ensure we know who a user is and that they are a valid customer (geographic, age, or other restrictions)
    • Do we need any additional requirements for our data? There might be a limit to what data is shown (PII/PHI and account numbers) or where it can be stored. We might be required to encrypt all data, store it separately from an account identifying number, or be allowed to transfer data across boundaries.
    • Do we need to utilize data updates? This need can be as simple as grabbing the latest valid zip codes or ICD10 values or something much more complex like current tax calculations.
    • Do we need multilingual support and unique access? These sorts of requirements can range from allowing users to use the application in their native language to access for blind or other impaired users that take advantage of screen readers and other technology.

    Data and Reporting Requirements

    • Part 1: Are there additional reporting requirements? This may seem like a minor addition. However, we cannot report on data we do not have. Thus, we may need to store more data than we intended. That can include audit information and complex data change logging.
    • Part 2: Are there additional reporting requirements? For example, we might need to integrate with systems to report tax, sales, or other data.
    • Are there disaster recovery or backup specifications to be met? Not all software has a life-or-death level problem it address. However, industry requirements exist for our systems’ availability or at least some confidence that the data will not be lost.
    • Do we need to keep records for a certain length of time? Data can pile up quickly, and sometimes it is easiest to purge old data from a system regularly. Unfortunately, that is not always possible. There are reporting requirements that can go back five or more years.

    Need To Know

    The difference with industry requirements or regulations is that we can not get around them. Some restrictions can make it very difficult to retrofit our design to support them. When we plan with these in mind, it is very helpful. It might even be a critical factor in our success. Likewise, no one likes to be deep into a project and hear, “oh, did I forget to mention this requirement?”

    Signing Off On This Question

    This question may be as simple as a “no” answer or require a document. HIPPA and other compliance requirements can be lengthy and require an expert to help you navigate how to build a compliant product. A project can start without a complete answer to this question. However, the sooner you have a full response, the better. That minimizes the chances that the design needs to be reworked down the road.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • How Soon Do You Need It? – Quick Solutions

    How Soon Do You Need It? – Quick Solutions

    Monetary cost is a crucial ingredient to any project plan. However, time is also essential. Quick solutions almost always cost more and have lower quality due to constraints on building them. The three-legged stool is time-money-resources, and that last one pulls less weight. There is often a limit to the impact resources can make. You can not get nine women to make a baby in one month. While this holds for all three of those constraints, time may be the most valuable to have in abundance.

    Quick Solutions vs. Better Ones

    Sometimes, a project or product can be done quickly and still be of high quality. Unfortunately, that is rarely the case. Instead, we must put in the hours and work to think through the problem and adequately craft an answer. Thus, the more time you have to work on the product or application, the more freedom you have to adjust for finances, resources, and quality. That makes it tempting to get a product built and shipped or installed, but its usefulness will be questionable. You would not want a doctor to rush through surgery. Likewise, rushed software is terrible software. That is one of the reasons projects so often fail.

    Setting Your Time Limits

    Timing is a difficult question to answer. Of course, we always want something sooner rather than later. However, there are hard limits to your schedule that come from various factors.

    • A commercial product launch window
    • Financial or Calendar year
    • Business and compliance deadlines
    • Seasonal or cyclical needs
    • Synchronize with business plans
    • Return on investment
    • Quality

    These are essential constraints that can help you answer the timing question and might push you towards or away from quick solutions.

    A Launch Window

    Even the best solutions have a lifespan and window of opportunity. We must meet those market deadlines for our product to be viable. Sometimes, that is a wide window, and sometimes, a tight fit. You might be forced to adjust features to squeeze it in this constraint. For example, you might know you can be first to market if you ship by a specific date and need that advantage. You can research the IDE tools released in the early ’90s when Java hit the scene to see how those things can play out. There were a few lower quality tools that aimed for first to market.

    Annual and Cyclical Targets

    Launch windows can be tough to determine. Others are hard deadlines and easy to factor in. A good example is when you are releasing a solution or features that will impact accounting. Whether it is monthly reports or payroll, there are times when mistakes during product release can be devastating. This is why many companies have quiet periods around the busy sales months.

    Synchronizing the Release

    There are other tasks related to product releases that are not technical. These include sales and marketing materials, training, packaging, and more. These related tasks can add time constraints that we need to include. On the other hand, these same tasks can sometimes give us more time than we expected. For example, when we miss a cyclical target, we can add weeks or more to our release window to achieve our objectives before the next cycle.

    ROI and Quality

    We all have seen products just shoved out the door to make a quick return. While that is a viable business model, it is rarely sustainable. If you have quick solutions of low quality, then you need to make your ROI quickly before everyone sees you have an inferior product. A high-quality product can increase your ROI and shift your focus towards a better product later rather than lower quality sooner. These business decisions are essential to decide when you start your project.

    Signing Off On This Question

    This question can be answered in a few ways. There is the desired time frame or deadlines, and then there are alternatives. You may not have an alternative. There are cases where you must have a product available by a specific date or timeframe to make it viable. Other times allow for multiple time windows, and you should have plans that consider those. That might also point to a phased release with an MVP for the first deadline and enhancements to follow. In any case, know what you are working with before you begin.

    Improve Software Success

    We have an e-book that can help you explore all the steps in building software, including a few templates. We ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.