Great Products Consulting

Tag: requirements writing

  • What are acceptance criteria?

    What are acceptance criteria?

    Acceptance criteria define what the system needs to be able to do in order to be considered ‘complete’ from a software development point of view. In essence, they’re a set of tests that you conduct to confirm that your platform or app does what you want it to.

    In this article, I’ll look at what they look like and how you use them.

    What are acceptance criteria?

    For each requirement that you have for your platform or app, you should also have one or more acceptance criteria. These criteria describe how your system is expected to work – both in terms of a “normal” scenario, but also when a user does something that they shouldn’t have.

    A commonly used structure for framing your acceptance criteria is as follows:

    <b>Given</b> [a particular scenario]

    <b>When</b> [the following steps are completed]

    <b>Then</b> [the expected outcome happens]

    This handy approach ensures that you fill in each part for a complete statement of acceptance.

    Examples of acceptance criteria

    Let’s say you’re building a marketplace to connect freelancers with potential customers. For the search function, you might have the following acceptance criteria:

    Given I am looking for a developer in Australia,
    When I enter “developer” in the keyword search field, select “Australia” from the drop down field, and click the search button,
    Then the search results screen displays with a list of developers from Australia, their rating, and their indicative hourly rate; with the results sorted by rating.

    To go even further, your acceptance criteria may also include the following:

    Given that I have searched for Australian developers,
    When I click on the header of the hourly rate column,
    Then the search results are sorted by hourly rate from lowest to highest.

    You’ll want to write acceptance criteria for each feature. This will ensure that you’ve covered all parts of the process. However, you may not cover every single scenario that occurs – simply because your acceptance criteria would go on forever!

    How do you use them?

    So now that you know what acceptance criteria are, how should you use them? Most obviously, you’re using acceptance criteria to test what your developers have done. You’re making sure that your platform or app works the way that you expect.

    By having your acceptance criteria written out, you now have a systematic way to test – and retest your platform or app. This also allows you and your developers to know what you did if something goes wrong. If you just went into your system, started playing around, it would be very difficult to recreate the problem.  With written criteria, you can repeat the test to see if the same thing goes wrong again.

    Thinking about your acceptance criteria is also a useful tool to help you define what you want your product to do. If you start thinking about what your acceptance criteria might be when you write your requirements, it actually helps your mind work through the things that the product needs to do. This will give you a more complete set of requirements.

    Acceptance criteria are an important part of the software and product development process. Along with giving you some help in writing your requirements and a systematic approach to testing, acceptance criteria also give you and your developers a benchmark for what you expect your system to be able to do. So, take the time to write out your acceptance criteria as they’re a critical component for building your platform or app.

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • Why you need to focus on “what” not “how” (when defining your product)

    Why you need to focus on “what” not “how” (when defining your product)

    In order to turn your online platform  or app idea into a living and breathing thing, you need to define your product. This means that you have to define “what” your product will do. The key word here is “what”. There’s a common pitfall when defining your product to focus on “how” you want you product to work – rather than “what” you want your product to do.   That’s a very dangerous thing when building software. 

    So, what’s the difference between “what” and “how”?

    “What” is looking at the features and functions for your product. It addresses the processes, the activities, the decisions that users and the system need to make, and the inputs and outputs that will make up your product. There’s a lot here, and it’s key to getting the product that you want.

    “How”, on the other hand, looks at the design of your product – the way in which the “what” is achieved. This includes screens, user experience, technical architecture, database structures, programs.  It’s all about how your product will be delivered. 

    Examples of “what” and “how” when defining your product

    In practical terms, the difference between the two can be illustrated as follows. If you have an idea for an app that matches buyers and sellers, you might define your product by saying “I want my app to capture and store personal information about the buyer so that they don’t have to re-enter it each time they make a purchase; resulting in a faster purchase time.” 

    Alternatively, you might say, “I want my app to have a screen with a form where the buyer enters their personal information and then when they make a purchase, there should be a button for them to use their stored information.”

    What’s the difference between the two examples?

    The first statement is based on “what” the app will do. It focuses on the activities of the user, and the expectations of the system to provide the customer with a benefit. The second statement looks at “how” you want to capture the information, and “how” the information should be retrieved.

    It’s not always so clear cut and it can be easy to get confused, but if you think about the “what” as being independent of any technical solution, then you’re on the right track. If you start to prescribe the solution that you want the develop to build, you’ve ventured into “how”.

    So, what’s wrong with that, you might ask?

    The biggest reason that you don’t want to define your product based on “how” is that you make assumptions about technical and functional design that may not be in the best interest of your product.   In software development, the “how” should be a response to the “what”. 

    If you talk about how you want things to work, it may result in your developer having to add complexity to your product that is unnecessarily or it might affect the performance of your product. This is likely to cost you more money upfront and in the future. By focusing on “what”, the developer has the freedom to find the best solution to achieve your desired result.

    Let’s go back to our examples. If you tell your developer you want a form, there’s a good bet that you’ll get a form – but is that the best way to capture the information? Perhaps there’s a way to get the information that results in a better user experience. Unless you have a good developer, you’ll never know, because the developer will just build what you ask for.

    Probably the most important reason to focus on the “what” is your customer. Ultimately, you want to build a product that does what they want it to do, and allows them to achieve the benefit that they’re looking for. If you focus on the “how”, there’s a good chance you’ll miss that piece and end up with functionality that nobody uses. 

    Wrapping up…

    Let’s face it, looking at “how” your end product will work is pretty sexy. You get to think about what’s on this screen and that screen. Making decisions about design is a lot more fun than thinking about users, tasks, and benefits. 

    Yes, looking at “what” is kind of an ideal state. Depending on your budget and the developer you hire, you may have to delve into the “how” and the world of design. No problem. However, before you do that, start with the “what” first.  It’s not an either/or situation.

    Ultimately, your product needs to solve a problem. If you can’t break down that problem, and figure out what your customer needs to do – what your product needs to do – to solve that problem, how successful can your platform or app be?

    Need some help defining your product so that your developer understands what you want?
    Check out our requirements writing course.
  • 5 Foundations for non-tech people with platform or app ideas

    5 Foundations for non-tech people with platform or app ideas

    Software technology projects can be tough at the best of times, but what happens when you have an idea for an online platform or app,  and you’ve never done anything like it before?  In this article, I’ll explore some of the ways that non-technical people can get the foundations to set themselves up for success.

    As someone that’s been in the industry for a while, I can tell you that there’s no such thing as a “perfect” development project. However, if you come from a non-tech background, there will be things you just don’t know about, and frankly, it’ll make life more difficult for you. 

    Here are a few ways that you can get on the right foot:

    1. Understand the process
    2. Learn how to brief your developers
    3. Know what to build
    4. Keep on top of your development project
    5. Don’t forget the biz

    1. Understand the process

    Software and software-related product development processes are beasts in so many ways. The scope of knowledge and experience that people working in the industry have can be outstanding. Every day, I am awed by what people know and can do. So much goes on behind the scenes of tools, apps and applications that you use every day. This is not a journey where you can close your eyes and hope for the best. 

    While it’s not feasible or even necessary for you to become experts in this area – that can only happen over time – you should at least understand how the process works. You want to know what’s ahead of you and what’s expected of you. If you know how things are supposed to work, you can recognise when things are going wrong.

    2. Learn how to brief your developers

    A critical step in any product development process – not just a software one – is defining what you want (a.k.a writing requirements). When building online platforms and mobile apps, this is particularly difficult.  You have to describe your product, in detail, to someone who thinks in a completely different way than you do.

    Even the most basic digital products includes multiple features and functions. You’ll need to tell your developer what you expect each of those things to do. This means you have to become the expert on your product. There are many pitfalls and considerations when you write your requirements, and a non-tech person, you just won’t know what these are.

    Bottom line – if you can’t brief your developers properly, you won’t end up with the product that you want.

    3. Know what to build

    Along the lines of briefing your developer is actually understanding what you should be building. In software, you have an opportunity to test and learn.  

    As someone that’s not familiar with a very complex process, this presents a unique risk-mitigating option for you. Instead of pouring tons of time and money into an all-singing and all-dancing product, that may or may not make you enough money to pay off your investment – you can build it piece by piece. By knowing what to build, you have a greater chance of scaling and growing a product that people actually use. Ideally, you want to aim for the smallest possible product first.   

    4. Keep on top of your development project

    Once your development project is up and running, you can’t just sit back and wait for the finished product. Ultimately, as the owner of  your product, you want to make sure your developers are doing their job. You don’t want to wait until the end to find out what they’ve built is not what you expected.

    There are also lots of things along the way that can derail your project – both in terms of budget, schedule and what is delivered. Look for ways to be involved in your project. This might include regular status reports or meetings, design documents, sample screens, etc. If you can head potential minor issues before they become major problems, you’ll save yourself a lot of headaches.

    5. Don’t forget the biz

    Development costs are going to be one of the highest, if not, the highest cost that you’re going to have to get your product to market. The problem is, this often makes people forget about all of the other things that are needed to launch. 

    There are legal considerations around terms and conditions, and privacy. Make sure you protect yourself in terms of insurance and business structure. From an operations point of view, you also have to think about how to support your product – how will people contact you if they have a questions or a problem. An online platform or app is a 24 x 7 business so you need to think of the best way to handles inquiries. 

    The point is that your product is more than the platform or app you want to build. Products are often successful because of all of the other things that are needed to make it work.

    The bottom line

    Non-technical people build platforms and apps all of the time. 

    Sure, it would be less expensive if you were a developer, but then you probably wouldn’t have all of the other skills needed to launch and grow a product. 

    Gone are the days when you hire a developer, and trust that you’ll end up with what you want at the end. In these competitive times, knowledge is power. The more you know about software and product development, the more power you have to control your destiny. 

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!