Great Products Consulting

Author: Great Products Consulting

  • 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 kind of business do you want to be? (Startup vs Small Business)

    What kind of business do you want to be? (Startup vs Small Business)

    This week’s article came about as I was thinking about the types of people that I want to work with, and how to describe them. If you decide to start your own business, are you a startup, a small business or something else entirely? Does the guy who opens a takeaway restaurant down the street call himself an “entrepreneur”? Is a contractor a “freelancer” or a “small business”? What you call yourself and how you relate to terms like these is an important part of the approach you take in building and growing an online platform or mobile app.

    The word “startup” gets thrown around a lot in mainstream and social media, but it’s a term that can be misunderstood and create the wrong expectations. In this article, I’d like to highlight some of the differences between these two terms, and why you should think about what you want your business to be.

    Startups

    According to Startup Muster, an organisation researching the Australian startup ecosystem, a startup is “an early stage business that has a large addressable market that utilises technology to capture that market quickly”.  Startups tend to have lofty ambitions that lean towards world domination, which mean they have some distinctive characteristics:

    1. High-growth with large, long-term revenue and profit potential that requires large upfront investment
    2. Potentially disruptive where existing problems are solved or business models are created, which are totally different and innovative (or they are copying those that have done this recently)
    3. Seek funding from external parties such as angel investors and venture capitalists
    4. Have an exit strategy whereby they sell their business and probably move onto a new one

    Small businesses

    On the other hand, small businesses lean towards some different goals and different ways to get there:

    1. Slower growth with short-term revenue and profit goals; where they want to make money as soon as possible
    2. Platforms and apps that are not necessarily new or disruptive, but have a sufficient market to generate revenue
    3. Initially seek funding from family and friends, loans and grants
    4. Don’t have an exit strategy; rather the business should generate the income that they’re looking for

    Why I’ve been avoiding the word “startup”

    I’ve tried to avoid using “startup” in relation to the people that I want to advise because I feel there are tons of resources and options out there to help those that want to go down that route.

    Instead, I really want to help those wanting to create small businesses from their platform or app.  There are loads of you out there!  You might be looking to grow revenue in an existing businesses or looking for a change from your corporate role. The people that I can help the most may not identify as entrepreneurs or even a small business owners (yet!) All of these people are looking to generate immediate revenue with the aim of replacing or growing their current income.

    What does this mean for you?

    If you’re an existing business looking to build a platform or app to grow your business, then this might be a prompt to rethink your overall strategy for what you want to be and where you want to go. How much are you willing to invest in your platform or app? Being big requires a much larger upfront investment. Do you have the resources to do this?

    If you’re thinking about going out on your own, then this really applies to you. Do you want to be a startup or a small business? The approach you take to develop your platform or app will be completely different based on the choice that you make. Think about your reasons for going out on your own and building your product. Which of the above definitions aligns most with your reasons?      

    Regardless of whether you want to be a startup or a small business, having clarity about your goals will improve your chances of success. So, decide who you want to be, and go about making that dream a reality!

    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's a minimal viable product?
    What’s scope creep? (next) >>
  • 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) >>
  • What happens after you’ve launched your platform or app?

    What happens after you’ve launched your platform or app?

    You’ve made it! You’ve launched your online platform or mobile app and you hopefully have a steady stream of new users and customers. Now what?!   This article will give you an overview of life after launch.

    If you’ve read my previous article on product development and product management, you’ll know that your launch is just the beginning of your journey. Your platform or app has to be managed through its lifecycle. There’s a constant cycle of updates and improvements that you need to make on your product and you’ve got to be actively involved in what these should be. You also need to manage the day-to-day running of your product. There are three main areas to look at:

    1. Operations and Fixes
    2. Maintenance and Compliance
    3. New Features
    Operations and Fixes

    A platform or app is a 24 x 7 x 365 day product. That means that you’ve got to make sure that your product is available to your users all of the time. If it’s a mobile app that resides solely on a user’s phone, then you may have a bit of leeway, but if you’re an online SaaS (software as a service) platform or if your app links to a database somewhere, you need to make sure your users can access it whenever they want. Areas to think about here include customer support (how do they contact you when something goes wrong?), backup and recovery (how do you get your platform working again if it falls apart?), and issue management (how do you track and fix problems that arise through the everyday use of your product?)

    Maintenance and Compliance

    If you’ve got a mobile app, then maintaining your app is going to be a regular and potentially costly activity. Since your app resides on a mobile phone, you’ve got to keep it up-to-date with the latest phone operating system. Otherwise, it might stop working! Every time Apple or Google releases new major or incremental software updates for their phones, you’ve got to determine what changes might be required for your app.

    On the web side, maintenance updates will depend on how your platform was built. If it’s using Wordpress, then you need to stay current with new Wordpress and plugin updates. If you’re using a framework, and this changes, then you have to decide whether to adopt the new change – and so on.

    There’s also something called “compliance” and this is stuff that you’ve got to address. If you don’t, there’s a risk that you’ll get fined from a government or regulatory body. Examples of compliance may include privacy rules (e.g. GDPR) or the way in which you accept payments on your site.

    New Features

    This is the fun one! These are the changes that you make to your platform or app to make it better. However, you shouldn’t just whack in any new feature that comes to mind. Go through the product development process again and evaluate all of the new ideas that you’ve got for our product. A proper review of your ideas will allow you to identify which features you should spend money on and which ones you shouldn’t. Think about the tangible and justifiable benefits that the change will have on your platform or app. Things such as return on investment (the profit you make on any money that you spend) and the payback period (how long it takes to cover the cost of the investment) are important to consider. Don’t just add it because you think it’ll be cool! Research shows that 80% of features in applications have low or no value based on how often they’re used. So, think about whether you really need to make the investment or not.

    Key reasons for adding new features might include:

    • Aligning with your company vision and mission
    • Improving an existing user experience
    • Matching functionality in a competitor product
    • Addressing a new market that aligns with your strategic goals
    • Generating new revenue via a new opportunity
    What does this mean to you?

    If you have set up suitable processes for managing your day-to-day operations and issue management, I would start there. You want to keep any disruptions to users to a minimum, so having these processes in place will give you some piece of mind and will stop the panic when things go wrong (because they will!)

    There are a lot of ongoing costs for running and maintaining your platform or app, so you need to do is set aside a budget for it. Generally, you’re going to spend about 15-20% of your original development costs on maintenance and updates. Some industries may be higher than others due to ongoing compliance changes, and you may spend more on improvements in the early years as your user base grows.    

    Make sure your developers stay on top of your maintenance updates. Depending on the updates required, you might need to tell them what changes to make. For example, if there’s new legislation around privacy, you have to figure out what that means from a business point of view, and then work with the developer to determine what updates need to be made to your platform or app.  

    When it comes to adding new features, you should think about how often you want to launch them. If you’ve got a few things on the list, you might consider grouping them together and launching them at the same time. Having a plan and a process for how you identify and validate new features will ensure that you’re choosing the right things to build.

    Launching your platform or app is actually the beginning of an ongoing exercise in operations, maintenance and enhancement. Make sure your platform or app is looking at all of these things to ensure that your business can grow.

    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.
  • Waterfall vs Agile: An intro to development methodologies

    Waterfall vs Agile: An intro to development methodologies

    Waterfall and Agile are the two most comment methodologies used to build software (e.g. the programs and components that make your platform or app work). In a previous post, I went through the activities involved in software development.  These include requirements, design, build, test and implement. A methodology is the way in which those activities are completed.  It’s the process that you follow to complete the work required to build a platform or app. When you start working with developers, the topic of methodology will most likely come up, so I thought I would review these with you in this article.  

    Today, software is usually developed following one of two methodologies – waterfall or agile. In both methodologies, all of the activities in the software development still need to be completed – the difference is in how they are completed. To recap, the activities in software development are outlined in the diagram below:

    Waterfall

    Waterfall is the traditional software development methodology. In waterfall, you complete one activity at a time before you go onto the next one:

    Here, you start with defining what you want in the requirements phase. Once your requirements have been fully-defined, you go onto the design phase. After your solution has been designed, you go to the build phase. When the build is completed, you test. Finally, once the solution has been tested, it’s implemented.

    Since you must finish one activity before going onto the next one, waterfall requires that you know exactly what you want to build up-front. This means that the requirements for your platform or app have to be quite detailed. The benefit of doing this is that when you know what you want to build, you can get a fairly accurate estimate of how much it will cost.

    The challenge with waterfall is if you come up with changes or additional requirements during the project. In extreme cases, you may have to go back to the design phase and re-think the solution. This often results in the project costing more and taking longer to complete. However, in most cases, if you’ve thought through your requirements, you can get a cost and time estimate for making the change that won’t have too much impact on your project. Alternatively, it becomes something you add shortly after launch.

    Agile

    Agile is a modern methodology that promotes flexibility. There are actually a few different methodologies that fall under the agile bannerd, but the most popular is called “scrum”. In agile, you still need to go through the processes of defining what you want, designing a solution, building it, testing it and implementing it. However, some of these activities are now done in parallel:

    You start with high-level requirements of what you want to build and this is broken down into parts that are completed over a series of “sprints”. A sprint is generally defined by a fixed period of time, so you determine the contents of a sprint based on what can be completed in that time.

    During a sprint, it’s a collaborative process to flush out the details of what you’re building. You and the development team work together (at the same time) to design, build and test each part. Implementation can occur at the end of each sprint or at the end of the project. An important distinction to make here is that an implementation, doesn’t mean that the functionality is made publicly available. It’s basically saying that the software is in a state that it’s finished. You may complete multiple sprints before you’re ready to actually launch the functionality to world.  

    The important part of agile is the element of collaboration. The idea is that everyone is working on a part together, so as you talk about what you want, the designers and developers are figuring out how it will work, coding it, and then getting you to test it out. Given the focus of flexibility, there may be multiple iterations to get it right. It requires a lot of commitment from you to make decisions quickly so that the team can keep going. Also, if you run out of time in a sprint, any things that aren’t finished need to be moved to the next sprint.

    The tricky thing with agile is that the quotes that you get will be based on high-level requirements. This means that as your project evolves, you may find more and more things that need to be included or the building of your platform or app may be more complicated than originally estimated. Your project will end up taking longer and cost more to complete. Contractually, it’s also harder to hold your developers accountable to what is delivered, because you don’t have detailed requirements to include in the contract.  

    So, which methodology should you use?

    If you’re just starting out in software development, the concepts of “requirements”, “design”, “build”, “test” and “implement” are all still new to you. You’re probably not sure what you have to do and you’ve got limited funds, so you want to know that your product will get built for the amount that you’ve allocated. If you have to spend time ironing out what you want to build with your developers, you’ll pay for that privilege. So, in this case, I would go suggest following a waterfall methodology.  

    This is probably going to be pretty controversial with some of the developers and agencies that you come across. However, I believe that agile works best with a trusted team (like a co-founder or full-time employee scenario), where you’re not counting the hours to get something done. Everyone on the team (including you) needs to know what to do to make each sprint count. You don’t want to run out of money before you finish building your product! You’re also dealing with a very small team – probably 3 or 4 at the most. Agile has more benefit with larger teams where people are working on different, but related things, at the same time. If you’re dead set on agile, I suggest switching after your initial launch. You and your developers will be more comfortable working together and it’ll be a lot easier to work in an agile way.

     I do have a caveat on this. I also advocate starting with the smallest possible project that you can. It’s much easier to start small and build on something that already exists. Compare that to starting with a massive project, which will carry with it a lot more risk. Remember that you can always implement without launching, so the waterfall approach can become pseudo-agile with lots of small projects. This will allow you obtain some of the benefits of agile, while allowing you to gain experience on how software development works and to get a more accurate estimate of the costs.      

    So there you have it – an introduction to waterfall and agile.  A basic understanding of these methodologies will give you some context into how developers and agencies build platforms and apps.  If you have any questions about this, please pop them in the comments below.

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • How do I make sure my platform or app works?

    How do I make sure my platform or app works?

    Testing is the step in the development process for making that your online web platform or mobile app works before you launch it. There are different types of testing to look at different aspects of your product, and then there is a process to actually plan and execute the testing. 

    In this week’s article, I’ll look at 5 steps for planning and executing your testing. These 5 steps primarily apply to application (system) testing, integration testing, user acceptance testing and beta testing. Performance testing is a different beast, as it requires some technical tools to complete.

    The 5 steps to make sure your platform or app works properly are:

    1. Creating a test strategy
    2. Writing test scripts
    3. Preparing for testing
    4. Executing the testing
    5. Reviewing the results
    1. Creating a test strategy

    For each type of testing, you want to start by creating a test strategy. This outlines all of the pieces required to do the testing including:

    • What you’re going test
    • When you’re going to do the testing
    • What your goals are
    • How you’re going to do the testing
    • Where you’re going to test
    • What you’ll test each day of the testing
    • Who needs to be involved
    • How will problems be resolved
    • What the entry/exit criteria are (e.g. what must be completed before the testing can start/end)
    • How you’ll track the progress of the testing

    This can be a list of bullet points or it can be a detailed paragraphs. The point is that you think about these things before you start your testing.

    Your developer may already have tools and processes in place for some of these things, but it’ll be up to you to find out what these are and to see if they are adequate for your testing.

    There’s also such as thing as “over-testing” – where you test until things are perfect. While it seems like the ideal thing to do, one thing you need to know is that most software is launched with known bugs and issues – they’re just not serious ones. As you create your test strategy, factor this into your entry and exit criteria so that you don’t end up testing forever and never launching!

    2. Writing test scripts

    Once you’ve created your strategy, you need to write some test scripts (or “acceptance criteria”) for what you’re going to test. These scripts describe what you’re testing, step-by-step instructions for completing an activity and what you expect the outcome to be. You need to create scripts for all of the functionality that you describe in your original product definition. This includes all of the “normal” scenarios and any “exception” scenarios.

    Doing this is going to be a big task, but it makes things a lot easier during the testing as you know exactly what you need to do and what you’re expecting your platform or app to do.       

    3. Preparing for testing

    This step is about looking at your test strategy and making sure all of the pieces are in place – have you got the resources that you need? Has the issue management process been set up? Is the testing site ready? Have the entry criteria been met?  You want to hit the ground running when the testing starts.  You don’t want to waste time and delay the testing because something isn’t ready.

    Preparing for testing is extremely important for beta testing if you’re coordinating a lot of people.  You need to make sure that they have the right setup and proper instructions, so they can perform the testing.  It doesn’t inspire confidence if people have to wait around for you or if your testers aren’t given the right direction! 

    4. Executing the testing

    Execution is about completing your test scripts according to the schedule that you’ve defined. You follow the steps in your scripts and if something doesn’t work, you notify your developer to fix it. You should document your findings – including screen captures – so that if something does go wrong, you can go back and look at what you did.

    During the testing, you also need to track and monitor your progress to make sure you meet your timelines, and to make sure your platform or app is working correctly.

    5. Review the results

    This last step is an important one.  You want to make sure you’re happy with the outcome of your testing. As you track and monitor your testing, you get a feel for how well your platform or app is working. You look at the number of issues that you encounter, and see how many test scripts that you’ve been able to complete successfully. If there are lots of issues, then you may want to pause the testing until some of the issues have been fixed.  You should keep testing until your exit criteria have been met.

    Why do I need to do all of this?

    As discussed last week, you want to make sure that your product works! You want to ensure the best experience for users, and broken functions don’t inspire confidence or positive references. 

    Another reason for going through this process is you need to be clear about what you want to test, so you can be happy your platform or app works properly! You also need to align with your development team on what you expect so that they can meet those expectations.

    Finally, in order to be effective, testing needs to be done in a way that is specific and repeatable. If you do something and it doesn’t work, the first thing that the developer is going to want to do is recreate the problem. If you can’t tell them what you did, then they can’t figure out what went wrong. Also, when the problem is fixed, you need to re-test the functionality in the same way to make sure that the fix works.

    Testing – despite it’s tediousness – is actually quite rewarding! You get to see your finished product in action, which is always exciting. You also assure yourself that your product works the way that you want it to.

    Stuck on how to test your app? Sign up for a free 30-minute discovery session* to get you on the right track.

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to the discovery session. 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.

  • What are the different types of testing?

    What are the different types of testing?

    Did you know that there are different types of testing that should be done on your new online web platform or mobile app? Each type of testing has an important role to play in making sure that your end product works the way that you expect it to. In this article, I’ll describe the different types of testing so that you know what you have to do for your platform or app.

    Imagine that your launch your product and your first users can’t sign in. Imagine you have a massive growth spurt and your product can’t support the number of users trying to access the platform. In the life of a new product, this is bad news! 

    There is a good bet that your development team will not test your product in a way that will ensure that it works the way that you want it to – probably because you haven’t paid them to. Testing is a specialist activity so your developers are not likely to have the skills to do parts of it properly (their specialty is coding!) This means it’s up to you to drive the testing phase of your project.

    So, before you launch your product to the world, what types of testing do you need to do?

    At a high-level, there are 5 different types of testing that you’ll want to look at:

    • Application (or System) testing is about making sure everything within the platform/app works correctly from a features and functions point of view.
    • Integration testing is for making sure that the platform/app talks with all other applications correctly (think payment gateways, email automation, CRMs, etc.)
    • Performance testing is used to check the speed and responsiveness of the platform/app under different conditions.
    • User acceptance testing allows the business (e.g. you) to check that the platform/app works in the way that it’s expected to in view of all of the surrounding operational processes.
    • Beta testing puts your platform/app in the hands of “real” users so they can put it through the rigours of everyday use.

    Traditionally, in large corporates, the technology department will do the system, integration and performance testing. In your case, you’ll have to own this and you’ll probably combine system, integration and user acceptance testing all into one. The developers should be able to run performance testing (as it needs specialised tools to do this), but you’ll have to tell them what you expect should happen.

    There is one more type of testing that you’ll have to do. This is called “regression testing”. Regression testing is about making sure that any changes to a platform or app don’t affect what’s already there. So, if your developer fixes something, you’ll want to test that what was fixed now works, but you’ll also want to re-test some of the functionality that is related to that feature to make sure that the fix hasn’t broken something else.

    Testing under a waterfall methodology

    If you’re developing your platform or app using a waterfall methodology, then testing occurs after the “build” phase. You’ll probably do a combined system, integration and user acceptance test at that time for all of the functionality that has been built. In the meantime, your development team should do some performance testing to make sure your platform or app can deal with the volumes of users that you expect. Once all of that’s completed, you’ll want to do some beta testing as well.

    Testing under an agile methodology

    If you’re using an agile methodology to build your platform or app, then you’ll be doing some testing along the way. As each component is built, you’ll do some system testing and maybe some integration and user acceptance testing to make sure that each piece works. What you test will depend on the component being built and what has been built before it. For example, if you want a user to be able to create an account and then you want to send those details to an email automation tool, you can only test the “integration” after both of those pieces have been built.

    You’ll only be able to test your operational processes as part of your user acceptance testing (e.g. sending a welcome email) after you’ve added that to your email automation too. What this means is that you should do some integration and user acceptance testing after all of the coding has been completed. This will ensure that everything works together. Finally, look at doing some beta testing, so that you can get real people to put your product through its paces.

    In summary…

    You need to test your product to make sure that it works! There is nothing worse that launching a product only to have key features and functionality that don’t work properly.  

    There are different types of testing to do and each has a different purpose. Testing is a lot of work and the amount of effort should not be overlooked as you build your product. It’s such an important step to ensuring a successful launch. You’ll need to decide what types of testing that you want to do, so make sure you factor it into your timelines.

    Next week, we’ll look at how you actually do the testing.

    Want to learn more about how to test your platform or app? Sign up for a free 30-minute discovery session* to make sure your users can use your app!

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to the discovery session. 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.

  • The Story of the GPC Logo (and what it means to you)

    The Story of the GPC Logo (and what it means to you)

    For today’s blog post, I thought I’d share a story with you. This one, like most stories, comes with a lesson for you about building and growing your web platform or mobile app.

    The story begins about ten month ago, when a young (ahem) lady decided to go out on her own and start a new business. Even though a lot of people are shunning business cards these days, this lady decided that they were still worthwhile for handing out at networking events (and to give to family and friends!) So, to start, a logo and branding needed to be created.

    As most marketers will tell you, to create your brand, you need to understand a bit about who you are, what you want to do, what you stand for, who you plan to sell to, etc. All of these go to influence some important visual elements of your brand – the name of your business or product, the colours you use and the fonts that you pick.

    A logo – basically consists of some colours, and maybe an image and some text. Some might even have a picture. Seemingly a simple thing – but it says so much about your business, which is why it’s so important. You want people to say nice things about you!    

    There are lots of graphic designers out there who can help you come up with a brand and logo. However, if you’re even slightly creative or have a limited budget (like I did), then head to Canva where they have a category called “Logo” to get you started.  Canva basically allows to design and create visual things – think business cards, posters, presentations, social media images, product labels, etc.  

    People can spend ages coming up with a brand and logo. Lucky for me, it was fairly straight-forward. A flick through the available logo templates in Canva, some tweaking of colours, a change of font and voila, I had the start of a logo. I showed it to some trusted advisors (a.k.a. my artistic friends), updated a couple of things and I was done!

    What made it easy for me was that I knew I wanted a circle of some sort in my logo.

    “So why did you I want a circle in my logo?”, you might ask!

    Well, I wanted to reflect the circular nature of the software and product development processes. Most people think that you start with an idea for a web platform or mobile app, build it, launch it and then you’re done. In reality, the development never stops – which is why we call both software and product development – “lifecycles” (For more info on these processes, check out this article).

    Once you’ve launched your app, you find yourself in a constant cycle of updates. Some you have to do (e.g. operating system upgrades for mobile phones, new legislation, etc.) and some will be driven from your customers, and your business strategy and processes. If you’ve already spent a ton of money building your app and the thought of spending even more money on development makes you cringe, I’m sorry to tell you that you might have to revisit your numbers to fit this in. However, for the most part, these changes are actually a good thing – and it’s what makes software and product development pretty exciting.

    There’s a good bet that when you launched your product, the product that you ended up with is at least a little bit different from your original idea. You’ve learned a lot along the way and now it’s time to take your product to the next level! The cyclical approach to development ensures that you can continue to improve and grow your product. Pick the right changes to make, and your product will help you to achieve your goals.

    The circle in the GPC logo is not a solid one.

    Did you know that there are a lot of different ways that you can draw a circle? Canva certainly has a few! So, how did I end up with this one?

    Did you know that research suggests that only 16.2% of software development projects finish on-time, on-budget and with the features and functionality requested? (Chaos Report, The Standish Group, 2014) What an appalling stat!

    Despite the number of apps and web platforms that get created every year, software development is not a perfect science. There are so many places where things can go wrong – not defining your product well enough, picking the wrong things to build, hiring the wrong developers, testing the wrong things, not testing enough, testing too much… the list is endless. With so many potential points of failure, it’s definitely a tricky road to navigate.

    So, based on all of this, I wanted the GPC circle to reflect the imperfect nature of this process. It’s also why one of my main goals is to help my clients successfully complete their development projects.

    And that’s my story…

    The GPC logo was built to be simple, but meaningful.  I hope that my little story gives you some insight into building and growing your platform or app.

    The next time you see the GPC logo, think about how you’re going to prepare for the cyclical nature of developing your product, and how you can address some of the potential pitfalls along the way so that you can have successful development projects.

    If you want to discuss how you’re going to navigate the road to building and growing your app, sign up for a free 30-minute discovery session* to make sure you’re on the right track.

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to the discovery session. 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.

  • Customers vs users (what’s the difference and why do I care?)

    Customers vs users (what’s the difference and why do I care?)

    Do you know the difference between “customers” and “users”? When I was creating my requirements writing course, these terms created some confusion with the person editing my content. It got me thinking that not everyone knows the difference. So, I’ve written this article to shed some light on a concept that is actually pretty important when you’re defining your product.

    In this picture, I’ve summarised the relationship between customers and users and I’ll discuss each of these below. 

    Customers

    A customer is the person or entity that will be giving you money. Note that I didn’t say – “giving you money for your platform or app”. This is because you may actually make money from someone that will never access your web platform or mobile app!

    There are many ways to make money from an app. The most common is someone paying money to access the app or to access special features within your app. These are your direct customers. So, if you have a web platform that charges $99 a month, the person signing up to your app will be your customer.

    If you make money from selling advertising space, then your customer is not the person that signed up to your app. It’s now the people or companies that are advertising with you or the ad network you subscribe to. If you sell the analytics from your app, then your customers are the people or companies buying that information. These are your indirect customers.

    You may have more than one customer. If you’re creating a 2-sided marketplace of buyers and sellers and the sellers have to pay you a commission, then the seller is your customer. If you then put advertising on your website, then the people advertising on your site will also be customers.

    Users

    The users of your app cover a lot more ground than your customer. Users will be accessing your app for a specific purpose – and it may not be for obvious reasons. As mentioned above, your customers may or may not be one of your users.

    When you’re starting out with defining your product, create a list of users for your app. Let’s start with the people that will be primary users – the ones that will sign up for your app or download it onto their phone. Then there are users that are invited by your primary users to interact with your app. If you’ve got an invitation platform, then these are the people that receive an invitation. If you’ve got a fundraising platform or event ticketing platform, then your users will also be those that give money to the primary user. These are secondary users – whose experience with your platform is just as important as the primary users.

    Next, there are users that will be needed to run your app – the people that work behind the scenes. These are your operational users. There’s a good chance there will be some admin involved – people to manage the users, people to create reports, create/update content on the app, etc. There’s also going to be support people who will answer questions from your users and help them solve any problems they might have in the platform.  

    The next level of users includes people that are managing the business end of your app (e.g. management users). Here you may have to be a bit more creative. If you’re primarily doing this on your own, then you’re going to be wearing lots of hats. You need to put on those different hats and think about what you might need the application to do so that you manage your business.

    For example, as the owner, there’s a lot of reporting that you’ll want to look at to determine what improvements to make and how profitable your app is. You’ll also be in charge of the security of your user’s personal information, so there are security concerns. Have customers or users in the EU? What do you need to support GDPR? If you’re selling advertising space, then you need information on how users interact with your platform. As a marketer, you’ll want user information that you can use to get new customers, retain existing customers or increase the spending of existing customers. Your accountant will want sales information.      

    As you can see, your list of users might actually start to get a bit long. Of course, not all users are created equal in terms of their importance in your app. However, being aware of them will help you to define a better product.

    Why do you need to know this?

    Your app should be driven by the needs and problems of your users. So, if you don’t know who your users are, then you won’t be able to define your product. In my last post on defining your product, I discussed how the users of the app should drive your requirements (e.g. “As a [user]…”). Knowing who your users are and knowing what they need from the app, will make it a lot easier to create a complete product.

     Your customers are just as important. Even though they might not use your app. You have to create a product that is worth them spending money on. So, understanding their goals and objectives will help you to include the features, functions and data in your product that your customers need as well.    

     

    Want some help to define your customers and users? Send us your details and we’ll set you up with 30-minute discovery session to get you on the right track:

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. 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.