Great Products Consulting

Category: Define (Requirements)

  • What’s the Difference between UI and UX?

    What’s the Difference between UI and UX?

    This article is going to look at the topic of UI and UX. These two similar, but very different terms are often confused, and so I thought I’d take a moment to clarify.  At the heart of it, the difference lies in what each of them aims to accomplish. User interface (UI) is about aesthetics – making the system look good, while user experience (UX) is about a good (or great) customer journey through your platform or app.

    User Interface (UI)

    User interface is specific to what people see on the screen – colours, fonts, and styles. It also related to a persons interactions with objects on the screen, like buttons, links, tabs and scroll bars – the things that people click on or touch to use the system. 

    User experience (UX)

    User experience is all about how the user interacts with your platform or app. How do they complete tasks in a seamless and pleasant way.  It also extends to their whole experience when interacting with your business – from the time they find out about you, to when they buy and beyond. 

    True user experience goes back to the customer’s problems, need or goals. What are they trying to achieve and how does your platform help them to do that? Can your users solve their problems efficiently and effectively? How does your platform or app make it seem easy to solve their problem? At the end of the the day, it’s how they feel about your product.

    Great UI does not always mean great UX

    Icons are a great example for showing the difference between UI and UX. Icons look great from a UI point of view. A little picture to represent a feature or object instead of text. However, they’re not always that great from a UX perspective. 

    Some icons are universally recognised – a garbage can for “trash” or “delete”, or a magnifying glass for “search”. However, if you start creating icons for new functions that people don’t recognise, and they have to learn what that icon means before they know whether they want to use it or not – then you’ve created a bad UX. 

    But there are overlaps too…

    Let’s take a button as an example. 

    In UI, you look at the colour, shape and size of the button. You also determine the font, size and colour of the text,  as well as the location of the button on the screen relative to other elements. Sounds a little like UX doesn’t it? The way the button looks will also make it easy (or difficult) to use. Imagine a button so small that your thumb or finger can’t click on it, or one buried at the bottom of a page amongst some text where you can’t see it. 

    There are some UX pieces to this button as well. When your cursor clicks a button, it might change colour so that the user knows that the button has been clicked. Maybe there’s a tool tip when you hover over it to tell you what clicking the button will do. These UX elements can make your platform or app more user-friendly. 

    Hopefully, you’re starting to see how people can get confused between UI and UX. 

    Why you need to know the difference between UI and UX

    As you look at how to get your product built, you need people with good UI skills as well as good UX skills. Some people have both skills, but some don’t, so you want to understand a person’s capabilities before hiring them. Even if you go through an agency, it’s worth your time to find out how they deal with UI and UX. 

    Bottom line – things may be visually appealing and perform the function intended (good UI), but the user shouldn’t be frustrated because they can’t figure out how to use the function (bad UX). It turns out the two need each other if you want to make a great product, so keep that in mind as you head out on your development journey.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • How much detail do you need? (writing requirements)

    How much detail do you need? (writing requirements)

    When you start breaking down your idea and deciding what your platform or app needs to do, it can sometimes feel like Alice in the rabbit hole. In this article, I’m going to look at how much detail you need to get into when defining your product (aka writing requirements).   

    So, how do you get from an idea to something that actually does what you want it to?  Describing what you want your product to do is a skill that most people haven’t tried before. In a previous article, I gave you the basics for describing what you want. The difficulty is often in deciding how much detail you need to provide to your developer.

    When you sit down to think about what your product can do, you can find yourself writing and writing and writing with no end in sight. That’s because you’ve really started to think about what a user is doing as they interact with your platform or app. You’re also thinking about all of the possible scenarios that might occur. All of a sudden, something that seemed very simple, now involves a lot of things.

    How do you end up this way?!

    Let’s look at building a house.  You tell your builder that you want a 4-bedroom house.  Imagine what that house will look like.  Think about how many storeys it might have, how many other rooms there will be in your house, where the bathrooms will go, etc.  That list of things that you want can go on, and on, and on.

    The thing about building a house that is similar to a platform or app is that the end product can come down to some very minute things. While the frame of a house or app can be relatively high level, the end product is far from bare bones.  

    In order to have a finished house, you have to decide on some very cosmetic things – like paint colours and door knobs, but you also have to decide on some very functional things too. What kind of window dressing would you like? Heavy drapes may block out light and sound, but they can be difficult to clean. How about soft-close drawers that won’t slam on your fingers? Or a mixer taps in the bathroom rather than two individual ones?

    You make the same kinds of decisions for an app. What colours are in your brand? What size and shape should buttons be? Should you be able to filter or sort the search results? What should the filter options be? The cosmetic decisions are important for user experience and screen design, but it’s the functional ones that are important for your requirements. If you can’t describe what you want to do – in detail – then how can a developer build it?

    So, how much detail do you need for your requirements?

    The answer is an infuriating “it depends”.  The level of detail needed for your requirements will vary based on a number of factors:

    1. Your developers: more senior developers with be able to take a higher level of detail, ask questions and drill down to what’s needed. However, less experienced developers will need you to be more prescriptive about what you want. They’ll only code what’s written down on the page – even worse, they’ll make assumptions that you haven’t anticipated!
    2. Standard functions: there are a lot of things in a platform or app that are fairly well known. A log in page for example is fairly standard. You might not need to get into a lot of detail here. There are also other common functions like taking payments. However, there can be a lot of variation here too, so you may need to be more specific in your requirements.
    3. Complexity: this applies when you want the platform or app to do something that’s more complicated. It might involve more steps, lots of data or have multiple scenarios.  In this case, you probably want to provide more detail in your requirements. 
    4. How important is it to you?: The final factor is probably the best guideline of all. If you want something to work a particular way, then you need to include it in your requirements. The easiest way to ensure the you get what you want is to write it down.

    Why should you care?

    There are a few reasons why the level of detail is important. At the end of the day, the level of detail that you can provide about what you want will affect the development quote that you get. If you don’t have a lot of detail, then developers will make a lot of assumptions when giving you a quote. If those assumptions are incorrect, you’ll end up paying a lot more than the quote to get your product built.

    Also, the more that you think about what you want, the better you’ll get to know your product. An idea is so different from an actual platform or app, and you’ll find that even the simplest functions have nuances that you’ve never considered. The clearer you are about what you want, the easier it is to talk to people about it. Ultimately, you need to be the expert in your product, and that includes knowing exactly what it does, and the purpose of each feature and function. Otherwise, you’ll end up building functionality that no one uses. 

    One last note, don’t confuse detailed with lots of requirements and a large project. To begin with you want to aim for a small project with the bare number of detailed requirements. It’s the quality of those requirements that count.

    Need some help defining your product for your developers?
    Check out our requirements writing course.
  • Features vs Benefits (define your product based on benefits)

    Features vs Benefits (define your product based on benefits)

    The idea of focusing on benefits has been a common approach for marketing products and services for years. Tell your prospective customers and clients what they get out of using your product or service rather than focusing on what your product does. Did you know that this is important as you define your product as well? 

    Let’s start with the difference between features and benefits. If you haven’t guessed it already, features are the things that your product does. Being able to watch a video or draw a picture. On the other hand, benefits are all about the “why”. These are the reasons why people should be using your product. Focusing on benefits is a very powerful marketing technique. Products exist to solve problems. Therefore, if you can tell or show people how you do this, then you’re describing a benefit that can compel them to use your product.

    Define your product based on benefits

    Defining your product based on benefits is something that I’ve touched on before as I described how to get from a high-level requirement to a detailed one. Today, I want to expand on this to explain how focusing on benefits can help you build a better product.

    A user story is a way to describe what you want your product to do. The user story is structured as follows:

    As a [user], I want to be able to [perform a task], so that I can [obtain some benefit].

    Along with “what” the product is doing, the other two key parts of the user story are the user and the benefit. Notice how this ties into the way marketers have been telling you to know who your customer is, and how solving their problems will make them happy? 

    The same things are just as important when you’re defining your product. You want to know all of the people who will be interacting with your platform or app, and what they’re trying to get out of it. This approach will then make “what” you want to build a lot easier to define.

    Build the right product

    This leads into a very important point about how you define your product. I’ve previously talked about minimal viable products and small development projects. The idea is that you start with the smallest possible project to create some part of your minimal viable product. This allows you learn how software development projects work, and you don’t get sucked into building something that nobody wants. 

    This approach has other benefits too. Did you know research has shown that 80% of features in custom applications are not used? So, more than half of things that people develop for their platforms and apps are things that no one finds useful. Think about the time and money wasted building! This is where benefits come in. If the thing that you want your product to do isn’t providing a benefit to someone, then you don’t need it. The bigger the benefit, the more value a feature has – and that’s what you should be building.

    Wrap up…

    Understanding the difference between features and benefits is not just important to marketing your product.  It also plays a big part in defining your product as well. Utilise the user story construct to focus your product requirements on benefits, and think about the size and impact of those benefits to make sure you build features that people actually use. 

    If you want to turn your good idea into a great product, then my Idea to Launch Checklist is your plain-English guide to getting there. It’s available now for only $24.

  • How your pricing model affects the development of your product?

    How your pricing model affects the development of your product?

    Platform and app pricing plays an important part in the success of your product, but did you know that it has an impact on how developers build it? Today’s article will look at how your pricing model can affect what you want your product to do.

    The approach for monetising your platform or app will vary on a case-by-case basis. Some will charge from the beginning, some will be free forever (e.g. make money through advertising or selling data), while others will be free with paid upgrades (e.g freemium) or have tiered pricing based on usage. Then you have marketplaces and directories that charge one or both parties in a transaction.

    Pricing itself is a whole other article, but what I’m looking at today is how that decision can affect how your product is developed. You’ll want to consider these things as you define your product. I’ll highlight some of the things that you might want to think about with the following pricing options:

    • One-off upgrades
    • Access to additional features on an ongoing basis
    • User and usage limits
    • Marketplaces and directories
    • Non-standard pricing, discounts and introductory pricing

    One-off upgrades

    If your pricing model offers to remove advertising for a fee or to add features for a one-off fee, then you’ll fall into this category.

    When defining your product and writing your requirements, you need to think about what will be free and what won’t. It’s usually a basic upsell and isn’t too complex (you either have it or you don’t). This will be important to your developers as they’ll have to restrict access to functions for users that haven’t paid for it. They’ll have to get the system to recognise who has paid for it and who hasn’t. You’ll also need to how the customer will choose to upgrade and how to collect the payment.

    Access to features on an ongoing basis

    Unlike the above, this model involves charging people an ongoing subscription to access features and additional functionality. This time though, things can get complicated. Some things might be charged a one-off fee, while others require users to subscribe to a different plan.

    As you define your product, you’ll have to decide what people should have access to. It could be an option within a function (e.g. buy a paid picture for a project in Canva). Alternatively, the upgrade could be for a completely separate function (e.g. a “premium” plan to remove branding in a video-making platform). Spend some time thinking about what types of plans you want to have and what features and functions can be accessed in each.

    This model has payment considerations too that affect both technical development and business processes. Do you need to process one-off payments? Will users be able to downgrade a subscription? What happens if a recurring payment is declined?

    User and usage limits

    Another pricing model may charge based on the number of users. A lot of B2B platforms work this way. Pricing changes based on the number of people that access the platform or app. Alternatively, you may apply limits to what a user has access to. This might be the number of projects that can be created, the size of individual projects, or the amount of storage available.

    All of these models will require your platform to track the number of users and usage to see when the conditions are met. You also have to think about what happens when a user or business meets these thresholds.

    These models also have a frequency piece – how often do these limits apply? Will it monthly? yearly? etc.  Also, what will be the process for increasing the limits?

    Marketplaces and directories

    Unlike the above models, marketplaces and directories have two sets of users. There is someone to buy or search, and another to sell goods or provide a service.

    In this case, the main question is about who will pay. Then there are a set of functions around when people will pay, and how much you will charge them. Unlike the previous models, there are lot of different pricing options available – fixed fee, percentage fee, fixed plus percentage, minimums, maximums, bundles, etc.

    When you start charging in percentages, your platform will have to calculate these values, so you need to think about all of the rules that go along with this. If you decide to sell a bundle of 10, then the system will have to track as each one is used.

    Non-standard pricing, discounts and introductory pricing.

    When thinking about your pricing model, you also want to consider different pricing promotions that you might offer. While most payment providers will support one-off pricing, discount codes and recurring payments, you want to check out their ability to support introductory pricing (e.g. first year at a discount, etc) and instalment payments (e.g. pay the entire amount up front vs monthly repayments).  Your platform or app itself will have to recognise these different payment options and ensure your users are accessing the right features and functions.

    Wrapping up…

    As you can see, your pricing model is not just important to making money. Pricing can actually affect the definition of your product – which means it can cost more to build some models than others.  So, when you’re writing the requirements for your platform or app, take some time to consider how you will charge your customers. This will make sure that your pricing model can be incorporated in the development of your platform or app right for the beginning.

    If you want to turn your good idea into a great product, then my Idea to Launch Checklist is your plain-English guide to getting there. It’s available now for only $24.

  • What is a Wireframe?

    What is a Wireframe?

    A wireframe is a drawing of a screen as it might appear on a website, an online platform or a mobile app. Wireframes are very powerful tools for describing what you want to build, and for illustrating your idea. In this article, I’ll explain the different types of wireframes and how you can use them to create your platform or app.

    On the web and on mobile apps, screen design plays a key role in how your customer and users interact with your product. These designs are usually created by user experience (UX) designers; often with the input of graphic designers (some user experience designers have visual design skills as well).

    Wireframes in Product and Software Development

    Traditionally, screens would have been envisaged in the “design” phase of the development process. Developers and designers would sit together to determine how a user will move through the application, and what the screens should look like.  However, screens can play a vital role in explaining what a product should do. As a result, screen designs are edging their way into earlier phases of the software and product development processes.

    As you’re validating your idea during the “analyse” phase of product development, wireframes can used to test your product idea. You show the screens to potential customers so they can understand what you’re trying to do and what the product might look like. The screens can even be linked together so people can ‘navigate’ through a particular feature. The feedback is invaluable in terms of seeing how people interact with your idea.  You can also get their reaction to your solution and whether it solves their problem.

    In terms of defining your product (the “define” phase of product development and the “requirements” phase of software development), wireframes are a great way to illustrate to developers what you want your product to do. In some cases, people get UX designers involved here to get some detailed wireframes outlined before starting development. However, be aware that there’s often a strong dependency between what the screen looks like versus how things work behind the scenes. In some cases, the designed screens may have some technical constraints, so you might have to re-do some of the screens at a later date.

    Types of Wireframes

    Wireframes come in different levels of detail and each one of them has different uses when creating your product:

    1. Low-fidelity wireframes

    These wireframes are hand-drawn and very high-level. They show the overall placement of content on the screen using boxes to represent areas of content, and lines to represent text. These are often used to map out what screens are required, the flow of the screens and the high-level content (e.g. picture, text, button, menu bar, etc). The idea is that you don’t want to spend too much on the detail. You’ll use these “lo-fi” wireframes in the “analyse” and “define” phases as you’re just illustrating concepts.

    2. Medium-fidelity wireframes

    Lo-fi wireframes are converted into computerised images with software tools like Sketch or Balsamiq or even basic drawing tools like PowerPoint. The high-level content is replaced with additional details – such as what type of picture will be displayed, what content will be included (e.g. contact information, user registration), etc.

    3. High-fidelity wireframes

    High-fidelity (“hi-fi”) wireframes often look like graphical representations of the actual screens. User experience designers will provide actual fields on a form (e.g. field labels, field types – calendar, drop downs, radio buttons, etc), general spacing and navigation. Graphical or visual designers will fill in the pictures, colours, font types, logos, styling etc. Items on the screen are annotated to include design and development notes (e.g. click here to go to the home page).

    The diagram below shows the level of detail in different types of wireframes:

    In many cases, people don’t bother with hand-drawing screens, go straight to the computer, and call them lo-fi wireframes. Some people will skip that step altogether, and go straight to hi-fi wireframes. It doesn’t really matter what you do – it’s more a matter of how much time and money you want to spend on it. It’s much quicker to hand-draw something rather than to put it on a computer. If you end up with multiple iterations of your screens or end up with new screens altogether, you spend less time and money doing this when you’re drawing boxes and lines versus very detailed screens.

    It’s important to remember that during “analyse” and “define/requirements” activities, wireframes should be focused on “what” rather than “how”. You don’t want to restrict your developers by telling them “how” you want something done.  Wireframes should be used to show them “what” people should be able to do, and the outcomes or benefits they expect from using your product.

    Why should you care?

    Depending on your budget and skills, you need to determine whether you want to create your wireframes or get someone to do it for you. You may want to draw low- or even medium- fidelity wireframes, and then pass them on to a designer. Alternatively, you may decide that your strengths lie elsewhere, and you hire a designer to do the wireframes from scratch. If it’s the latter, then you’ll still need to provide some guidelines to your designers, and this can be done in your product definition.  This instructs the designer on what the product should do.

    Either way, knowing how to draw wireframes, and understanding the different levels of detail are important skills to have. Pictures are a very powerful communication tool, and can be used throughout the development process to show developers what you want them to do.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • Get from “idea to launch” with my new checklist!

    Get from “idea to launch” with my new checklist!

    If you’ve got a great idea for an online platform or mobile app, but you’re not sure where to start – you’re not alone. Tech can be intimidating for those that have never had any experience with it before. Sometimes you want someone to guide you through the process – but you just can’t afford to hire someone to help you.

    The good news is that building an online platform or mobile app is a process.  This means there are clearly defined activities that you can follow to reach your end goal. Once you know this, the whole thing becomes more manageable – you just have to take it one step at a time.      

    Introducing the idea to launch checklist

    Today, I’m pleased to introduce the “idea to launch checklist”. This downloadable checklist contains “must-know” tasks in 15 core areas, so you can turn your good idea into a great product. It provides a plain-English roadmap for your journey. You’ll see the main activities for developing a product, and the tasks involved in each step.

    The idea to launch checklist came about as a way to take non-technical people through the creation of a digital product. Like the design and manufacturing of any product or service, platforms and apps have their own brand of jargon and their own unique complexities.  This checklist needed to be written in a way that anyone could follow.

    I understand that not everyone wants to be an expert in software development. Business owners and working professionals certainly have enough things to do and learn! This checklist has been designed with you in mind. If you’re serious about building your own digital product, then the information in this foundational checklist is definitely in the “need to know” bucket. 

    Did you know that on average only 16.2% of software projects are completed on-time, on-budget and with the features and functions originally requested?

    Having worked on technology projects for almost 20 years, I’ve learnt a lot about software development – to a point where it’s mostly routine and I don’t have to think about what to do. Throw in 8+ years in product management, and there’s all of this experience that I took for granted.

    It made me realise that this lack of knowledge is costing people money.  I’m sure people would learn a lot from their experience, but I think they would prefer not to spend so much money on those lessons!

    As someone that’s been doing this for so many years, I really want to help people avoid this situation. So, I’m sharing my experiences and knowledge with people that have had their “light-bulb” idea, and are ready to do something about it.

    Here’s a taste of what you can expect from my checklist:

    • 21 ways to evaluate your idea. Let’s be real – you need to know if you’re backing the right horse.
    • 20 critical steps to finding the perfect developer. This is not the time for speed dating.  A bad decision will cost you time and money and could even delay your product going to market.
    • Plus 25 tasks that will ensure your product testing is rigorous and effective…. If you’re really going to do this, you want to do it right.

    Think about it – you can’t ride a bike the first time you try it. In fact, before you perfected riding on two-wheels, there’s a good chance you rode a tricycle or had training wheels. You also probably fell a few times.  Maybe you could only make it to the end of the driveway before putting your foot down. Eventually though, you made it to the end of the block and around the park a few times.  

    Building digital products is much the same as this. That’s just the way life is. It often takes a few goes around the block before you’re comfortable with what needs to be done. You can try it with two-wheels for the first time without the training wheels, or you can get some help to make it easier on yourself.

    This foundational checklist is all about action. I want to see you get that platform or app built, and I want you to get there in a straight-line path. So, if you’re ready to build your platform or app, click here to find out more.

  • What’s in your platform or app? (Product Definition)

    What’s in your platform or app? (Product Definition)

    Taking your idea and making it into a product involves a very important step around defining what you want your product to do. This product definition (or product requirements) form the foundation for what happens next, so you need to take some time to understand what you need to look at.

    Previously, I showed you how to write high-level and detailed requirements. In this article, I’m going to look at how a product or service is made up of more than just the thing you use it for. Think about the last time you used a platform or app. How did you interact with it? Along with the core thing that it did for you, what else happened? This will get you thinking about what your whole product will look like.

    Let’s look at example:

    AirBnB allows people with rooms or houses to rent them to people who are looking for rooms or houses. The core things that it allows renters to do includes:

    • Searching for rooms and properties
    • Making a booking (pay and reserve accommodation)

    This is the essence of the service. There are obviously other things that you can do – like book experiences, cancel bookings, leave a review, etc. People supplying the accommodation (aka hosts) also have access to a whole bunch of other features – from listing their accommodation to managing their bookings.  All of these things are  functions in the product.

    I want you to start thinking about the other things that are needed to make your platform work.  So, let’s get started.

    1. Privacy and Data Security

    In order to make a booking on AirBnB, you need to create an account. To do that, the platform needs to collect a person’s personal information including name, address, phone number, email addresses and payment information. This information requires special handling and treatment because of privacy legislation. Privacy and data security are two very important areas to keep in mind when you’re defining your product.

    2. Legal

    When you open an account on any online platform, you might notice a checkbox that says “I agree to the Terms and Conditions”.  This little box is very important.  When someone checks that box, it creates a contract between you and that person.  This contract allows you to do things like charge the person for using the platform, and it also limits your liability if something goes wrong.  Get a lawyer to create your terms and conditions to ensure you get the best protection.

    3. User Account Management

    Once someone has created an account, they’ll probably need to update it at some point. User account management is another function that you need to think about. What information can someone change on the account? What other things will they be able to add or control in their profile?

    4. Pricing

    Your pricing model will have a big impact on the development of your platform or app. It’s pretty straight forward with AirBnB because you pay a rate per night and a cleaning fee (as determined by the host), and you also pay a service fee. However, some platforms are a bit more complicated – having different pricing based on usage, number or resources or accessible features. All of the rules for this kind of pricing have to be built into the platform.

    5. Customer Servicing

    What happens when a customer has a question about how the platform works? Or maybe they can’t login and access their booking? Customer servicing is an important part of any product – and platforms and apps are no different. Think about what methods you want to use to provide customers with a great experience – both on an everyday basis and when things go wrong. What process will be followed? What will you need access to in order to provide support to your customer?

    6. Data and Reporting

    On the business side of things, you need to think about what information you need to understand how well your platform or app is doing. Access to data and reporting are a must-have when running a tech business. Think about what metrics will be important to you, and how you want to receive that information – is it a dashboard, a report or a .CSV file, etc?

    7. Admin

    There are a lot of things that happen behind the scenes to run and operate a product. All of these admin functions need to be included in your platform or app.   May be a customer’s account needs to be updated? Or may be you need to add content on a regular basis? These tasks should also be included in your product definition.

    8. Integrations

    Integrations involve connecting your platform or app to another application. This might include email automation systems, a CRM, a payment gateway (to collect payments), an accounting system, etc. What other applications do you need to run and operate your product?

    What this means for you…

    An idea is initial view of the main thing that your platform or app will do. It describes the problem that you want to address and your high-level solution for it. However, a developer can’t build a platform or app from an idea. In order to get your product built, you need to have a better idea of all of the things that you want your platform or app do – this is your product definition.

    More importantly though, you have to remember that a product is more than just the core things that it does. There are lots of surrounding parts that are needed to run and operate the product. Remember to include these pieces as you take your idea to the next stage. They’ll help you to get an accurate quote for your project and you’ll be in a better position to run and operate your product as a business.

    Need some help defining your product for your developers?
    Check out our requirements writing course.

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

  • How do I prioritise what I want? (requirement prioritisation)

    How do I prioritise what I want? (requirement prioritisation)

    Prioritisation is probably a concept that you’re familiar with – you take a list of things and figure out which ones are more important than the other ones. Sounds simple enough?!

    When you’re building an online web platform or mobile app, prioritisation comes up all of the time! In this article, I’ll look at prioritisation as it relates to defining what you want your product to do. This notion of requirement prioritisation is a difficult one to grasp – because everything is important!  I’m going to take you through this process and share some tips for prioritising what you want.

    What are you prioritising?

    Requirements describe what you want your product to do. Requirements range from high-level statements (e.g. The user will be able to create an account) to detailed statements (e.g. The user will be able to create an account with their first name, an email address and a password). Every requirement needs a priority so you know how important it is.  

    Prioritisation methods

    There are really two main prioritisation methods:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have; and
    2. Ranking

    Let’s look at each of these in a bit more detail:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have

    This is a simple categorisation of your requirements based on the following criteria:

    1. High/Must Have: These are the things that have to be there in order to launch your product. They are critical to the success of your product. If these things don’t work, you have to delay your launch until things are fixed.
    2. Medium/Should Have: These are the things that “should” be there for the launch of your product, but don’t stop the launch from going ahead if they’re not built or not working properly.
    3. Low/Nice to Have: These are the extra things that you’d like your product to do, but they’re not all that important to your product right now.

    All of your requirements are given one of these priorities. Initially, your product will be focused on the “high priority” requirements, and if there’s time and money, the “medium priority” requirements can be included. Generally, your “low priority” requirements will be built after your initial launch.  

    2. Ranking

    Ranking is a straight-forward list that starts from 1 (the most important) and increases sequentially from there. It dictates the importance of one requirement relative to all other requirements. This is the method used in the Agile methodology to manage the list of things to be built. You start with 1, and keep going down the list until you reach your last requirement. You’ll have to decide which of the requirements on your list need to be included in your initial launch, and then you’ll continually develop your product after that.  As new requirements are discovered, these need to be slotted into the list based on their priority.

    How do you decide the priority?

    So, how do you decide if something is a “must have”? Which requirement is #1?

    There are several things to consider. Requirements are important if it’s:

    1. Critical to solving the main problem/need/goal you’re trying to address
    2. A legal, regulatory, or security requirement
    3. Needed for a satisfactory user experience
    4. Inclusion will help you to achieve your goals
    5. Driven by potential customer and user feedback

    The key is to be as objective as possible in setting your priorities. You may even have to test how important a requirement is by talking to potential customers and users. Prioritisation should be an informed business decision. Make sure you take the emotion out of it. You can’t make everything a “must have” – otherwise, you’ll never launch!

    Why is prioritisation important?

    You’ve prioritised all of your requirements, so how does this help you build your platform or app?

    Prioritisation comes into play when you’re deciding how much you want to build. Unless you’ve got all of the time and money in the world, you need to make decisions about what to include in your development project. If you’ve prioritised your requirements objectively, you start with your highest priority requirements first. Most people are constrained by their budgets, so prioritisation forces you to decide if you really need something or not.    

    Prioritisation also becomes a consistent and easy way to make decisions about your development project, and to communicate the importance of each requirement to your team. If a high-priority feature is taking longer than it should to build, or if there are issues with it during testing, then everyone knows what they should be working on.

    Prioritisation is ongoing

    After you’ve launched, you continue to add new features and functions to your product, and you’re going to have to decide what to build next. You should continue to prioritise these requirements, so that you can make objective decisions about the improvements you make to your platform or app. This will ensure that you’re spending your money on the right things – and that’s critical for your product’s success.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What's scope creep?
     
  • What’s scope creep?

    What’s scope creep?

    The term “scope creep” might conjure up images of spiders and other crawling insects, but it’s actually a real concept in software development. I introduced it in my article on “Tips for Building a Web Platform or Mobile App”, and now I’m going to expand on it to tell you why you need to be aware of it and how you can prevent it.

    Scope creep occurs when the size of a project increases after it has started due to the improper management of requirement changes.

    Huh?!

    Ok – say you have a project that starts with a list of 10 things to build. That’s the scope of your project. As you go through the project, you realise that there are another 5 things that you want to build. If you decide to include them in your project, your scope has grown by 50% to 15 things. That’s scope creep.    

    Why do you need to know about scope creep?

    Scope creep is an easy trap to fall into. When you’re building a product from scratch, there’s only so much that you know at the beginning. As you start the design and build process, you learn more about your product, and you think of more things you want your product to do. You want it to be perfect, so of course, you need to include it in the initial version of your product. The new requirement is added to your project – then another, and another – and all of a sudden, it takes months longer to finish the build of your product and costs you more.

    Your developers will love you! They get more money and you get the product that you want.

    So why is this bad?!

    Presumably, when you were planning to build your platform or app, you had a budget of some sort – the amount that you wanted to spend or could spend on development. Better still, you had an idea of the financials required to make your idea commercially viable (e.g. the numbers that you needed to hit to make money). If you fall into the scope creep trap, you might a) not have enough money to complete the building of your platform or app and b) your idea may no longer be commercially viable.

    This notion of scope creep also ties into my article the other week about a minimal viable product (MVP). People often have good intentions and start with building an MVP – and then they get excited – a competitor has this feature that you just have to include, and there’s this really cool feature that you think your users will love. Your initial release gets bigger and bigger, and is no longer an MVP. Also remember, that 80% of features in most applications don’t get used! There’s a good bet that many of your unplanned changes won’t materially affect your product in a positive way.

    What can you do to prevent scope creep?

    There are two main ways that you can prevent scope creep from happening.

    1. Define your product properly upfront
    2. Manage change to your product scope appropriately

    1. Define your product properly upfront

    Scope grows when you realise that there’s something else that needs to be included in your project. So, to prevent this from happening, you need to have a better idea of what you want to build upfront. This involves having a very clear, and often detailed, view of what you want your product to do. Take the time to think through every process and every function that defines your product.  You want to make sure you’ve captured different scenarios that might occur, and the features you want your product to have. This will allow you to have a well-defined scope for your project.

    The reality is that there’s going to be things that you miss – and that’s ok, because now you’re only going to miss a few things rather than lots of things. This is where the second method for dealing with scope creep comes in.

    2. Manage change to your project scope appropriately

    When you discover that there’s something else you need to add or change you to your product, then there’s a few things that you should do before you decide to actually build it:

    1. Prioritise the change: How important is it really? Do you need it in the first version or can it be something that’s added shortly after?  

    2. Get your developers to estimate the size and impact: Understand how much it will cost you to make the change, and how it will affect the overall project schedule.

     3. Evaluate the impact to your financials and business model: Use the numbers to see if you can afford to make the change. Does it affect the commercial viability of your product? Will delays disrupt your launch strategy? Do the benefits outweigh the costs?

    If you do all of this and decide the change is worth it, then go ahead and do it. This doesn’t have to be an extensive, drawn-out process. The point is that you’ve made an educated decision about changing the scope of your project.

    If you’re working under an agile methodology, recognise that your change may mean that something else doesn’t get done. This change may have a higher priority and cause another requirement to be pushed back. You’ve got to decide whether to extend your project to include the lower priority requirement or not.

    Not all change is bad…

    Despite all of this doom and gloom about scope creep, there are often very legitimate reasons for making changes to your project. The lesson here is that you don’t want to be caught unaware of what’s happening. It’s very easy to for a lot of small changes to accumulate and drive your costs up and delay your launch. So, before your start your project, be as sure of your can of what you want your product to do, and while you’re product is being developed, have a process in place so that you can make informed decisions about changes that you want to make to your product.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What kind of business do you want to be
     
  • What’s a minimal viable product? (and why start small)

    What’s a minimal viable product? (and why start small)

    A minimal viable product (MVP) is the smallest possible thing that you can build to tackle a core need, problem or goal that your product is trying to address. Other definitions include something that delivers customer value or something that allows you to learn more about your customers. In fact, an MVP is probably a mix of all of these things.

    Sounds simple enough? However, these definitions can result in confusion about what practically constitutes an MVP. The key message though is that it shouldn’t be the end product that you envision and it can’t be so basic that it doesn’t do anything.

    Why start with an MVP?

    An MVP is a good way to validate what your customers and users really want. They have something tangible to see and play with, and then you can get feedback on what’s good or bad and what else needs to be there. You solve their core problem or need, so you make them happy.

    Did you know that research shows that 80% of features in custom applications are not used? Imagine spending a whole ton of money on functions that just sit there untouched? What a waste of your precious time and money!

    If you’re constrained by time or money, then an MVP allows you to build something that can give you a foothold for you to grow from.

    “My competitors do ‘xyz’. My product needs to as well.”

    It’s so tempting to look at what your competitors are doing, and want to replicate it in order to attract customers and users. I totally get it! Remember though that your competitors probably didn’t have all of that to start.

    It comes back to your strategic competitive advantage and your value proposition. If the core of what your product is trying to address is included in the MVP, and even if this is only slightly better than your competitors, then you’re already ahead of the game.

    If the market is so mature that you need all of those features to launch, then I predict a tough ride ahead. Remember that your competitors may have deeper pockets than you, so if you release a new feature, they’ll likely copy it. You don’t want to go down that rabbit hole! Ultimately, you probably will need to build all of those features, but not for your MVP.

    “My customers or users are going to expect more. “

    In the world of software and product development, the word “launch” is actually a bit of a fluid term. At the point of releasing any new product, you’re at the introduction stage of the product lifecycle. You’re not dealing with thousands of users or customers.

    You want a core group that are going to sing your praises and get you the momentum you need to grow. This group of early adopters understands that your product is evolving and they want to be one the journey. At this stage, you have the opportunity and time to add the extra features that you need. Then, when you’re ready, you can put all of your marketing efforts into getting all of those customers and users, so you can hit the “growth” stage of your product.

    Why go even smaller?

    All of the above is said with my product manager hat on. Now, I’m going to talk about it from a software development perspective.

    Here’s the thing, if you’ve never built a platform or app, then you’re dealing with a lot of unknowns. This means that there are a lot of things that can go wrong. When things go wrong, it costs you time and money. You want to do everything you can to mitigate that risk.

    So, in the process of building your MVP, why not start even smaller? Start your development experience by building a small part of your MVP. Get it done – whacked out in a couple of weeks and all of a sudden you’ve got a product. A very rudimentary and non-commercial thing – but it works. All of a sudden, you’ve completed something that you’ve never done before.

    This is very important. In this experience of creating the first part of your product, you’ve also learned how software development really works. It’ll now be a lot easier to add to what you have built. Having a project to build all of the bells and whistles carries a lot more risk, than building something small and then continually adding to it. Something finished within two week or a month is way less risky than something that takes three months to build. Starting small also gives you a chance to test out your developer. If you’re not happy with how it all went, you can kick them to the curb with minimal impact.

    When you’ve built enough stuff to have an MVP, you can then “launch” it to your early adopters. In fact, why not try and get some of them involved even earlier? They can help you to prioritise what should be added to your product and they’ll be invested in its success.

    What next?

    At the end of the day, building an MVP is just one strategy for product development – albeit a very popular one right now. It’s not a blanket “must do”. Like anything, there are going to be exceptions to this. There are other strategies for building new products that you can choose from – people have been following them for years with success.  

    As you take your platform or app idea to the next step, think about your approach for building it for its first release. How much do you really need it all on launch? How much risk is involved? Would you be better off starting small and continually enhancing your product until it’s ready for your big launch?  Remember, sometimes it’s worth going with small in order to grow big.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
    << (previous) What happens after you've launched your platform or app
    What kind of business do you want to be? (next) >>