Great Products Consulting

Category: Define (Requirements)

  • What is Technical Debt?

    What is Technical Debt?

    As your developers are building your online platform or mobile app, you might acquire something called “technical debt”. There’s a chance that you’ll never be told about it – and you won’t even know what it is, so I wanted to write this article to make you aware of its existence.

    What is technical debt?

    There is no single way to build a platform or app. Like writing an article, people will approach it in different way, and as a result, the final output will achieve the same result but actually look different.

    The choices made during development – either by accident or deliberately – create technical debt. Technical debt is the amount of re-work that you may have to do to your product in the future to get the functionality that you want.

    Why does it happen?

    There are lots of different reasons why technical debt gets created. Here are two that you’re most likely to come across:

    1. Initial decisions related to the overall technical approach
    2. Incomplete or changing requirements

    Both of these can create technical debt that has a great impact on your future plans.

    1. Initial decisions related to the overall technical approach

    Usually, you’ll make a deliberate choice about how you will develop your platform or app.  The overall approach taken can create technical debt.

    For example, one way to build an online platform is to use an existing platform as the basis for your new product. Wordpress is a common approach. Alternatively, you can have a completely customised solution. They may both give you the functionality that you want, but there are pros and cons for each. For mobile apps, the decision is often between using a hybrid platform or building from scratch as a native app.

    This technical decision is often based around money. You want to spend the least amount of money possible to get you to market, so that you can start making money. There are other factors too, but most will boil down to the initial costs and development time.

    2. Incomplete or changing requirements

    Developers can only make technical decisions about what they know right now. If you don’t have a complete picture of what you want, or if you add or change something down the track, then there’s a risk of creating technical debt.

    The developers will craft a technical solutions based on the requirements that you give them. If you’re thorough in defining what you want your product to do, and all of the nuances around it, the developer now has more information to work with.

    Imagine you tell a builder that want a single-storey, two bedroom house – and then halfway through you decide you actually want a 2-storey house. All of a sudden, the builder has to change the way in which the house is built. Some of what has been built may stay the same, but there’s a chance that some stuff may have to be ripped out and re-built.

    What does it mean for you?

    Some technical debt cannot be avoided. You don’t know what you don’t know. That becomes part of the cost of doing business.

    Another part of technical should be a conscious and informed choice that you make. You may choose to go with one option because it gets you to market sooner. This reflects the uncertainty associated with building new products.

    The final part is something that you can avoid. Be clear about what you want. Especially with an agile development methodology, developers focus on what’s immediately ahead of them. It gives you some flexibility to change your mind. However, it creates technical debt. The best case though is for a developer to be aware of what you want from the very beginning. Any re-work is a cost to your business, and it’s money that you could spend elsewhere.

    With your new awareness of technical debt and how it is created, you should now be able to start a conversation with your developer that allows you to make informed and deliberate choices about your future platform or app.

     

    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.
  • What can you do to reduce the cost of building an online platform or mobile app?

    What can you do to reduce the cost of building an online platform or mobile app?

    In my last article, I looked at some of the major things that can affect the cost of building an online platform or mobile app. This article is going to look at some of the ways you can reduce your initial costs, without severely compromising your idea and the quality of the final product.

    The most effective way to reduce costs is to look at the following:

    1. Build less
    2. Reduce complexity
    3. Build for fewer devices

    1. Build Less

    It might sound obvious, but it’s a very difficult thing to do. How do you do decide what to cut out and what to keep? Often everything will seem important, and you’ll have to make some though choices. The reality is – research has shown that 80% of functionality for custom-built applications isn’t used, so as it turns out, there might be some features and functions that you don’t need for your launch.

    There’s an important thing to note here. Building less doesn’t mean that you never build the rest of the things that you want. What it does mean is you pick the things that your potential customers and users really want. Once they start paying you, you can afford to build more. Building less has other advantages around minimising the riskiness of your project.

    2. Reduce Complexity

    This one is probably a difficult if you don’t have any technical knowledge. How are you going to know if something is complex or not? Where building less is about the number of features and functions, reducing complexity is about what goes into each feature and function. It includes taking out steps in a process, and minimising the choices and scenarios that are possible. Generally, it’s about getting the platform or app to do less in the way of processing and calculating.  By reducing complexity, there are fewer places where things can go wrong.  When things go wrong, you have to pay more money to fix them.

    3. Build for fewer devices

    As I mentioned in my previous article, the more devices you build for, the more it costs. While responsive design deals with some of the differences in screen sizes, there will be cases where there just might not be enough space on a mobile phone screen. This means that you may have to adjust your design for mobile devices, and that means more designing, more coding, and more testing. With tablets and phones, and even laptops, your developers will also have to consider interactions with a mouse versus a touch screen.

    Why should you look to keep your costs low?

    No one wants to spend more money than they need to. However, people often go to a developer with a laundry list of things to do, and then get surprised by the amount they’re quoted.

    You might find that to reduce your costs, you may only need to do some of the things above.  By spending less money upfront, you can use the extra dollars in valuable updates after your product has launched.

    The more compelling reason for reducing your costs is actually around the uncertainty of making the money back. The more money you spend, the more you have to sell to make your money back, and to ultimately become profitable.

    Even if your most pessimistic business plans show you making money, it’s worth going through this exercise to see where you can cut the fat.  This can only mean more money in your pocket, so what have you go to lose?

    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 does it cost to build an online platform or mobile app?

    How much does it cost to build an online platform or mobile app?

    Cost is a big factor with any investment, and software development is no different. So, how much does it cost to build an online platform or mobile app?

    The answer – it depends. You might be able to get away with $10,000 or it might cost you $200,000+.

    Yes, an infuriating and vague response, but unfortunately, very true.

    Think along the lines of “how long is a piece string?” Software development projects can be small or they can be big. This, of course, affects the cost.

    Factors that can affect cost

    There are many things that can affect the cost of software development. Here are some main ones:

    1. What features and functionality you want (and how complicated it is)
    2. Who will build it
    3. How it will be built
    4. What devices need to be supported

    Let’s look at each of these in more detail.

    1. What features and functionality you want (and how complicated it is)

    There is a direct correlation between how much you want to build and the cost. An app with 50 functions is going to cost more than an app with 10. It just takes longer to build more, than to build less.

    The next part of this relates to how complicated the functionality is. We might both define a product with 10 functions, but they may differ in complexity. Mine might have lots of different rules, require lots of information to be captured and stored, and need lots of calculations to be completed. Yours may just be displaying different types of content that has been loaded into the system. Mine will probably cost more to build.

    2. Who will build it

    It’s no secret that going offshore will get you a lower daily rate than staying onshore. You’re probably looking at a difference of $50-$75 per hour. This can add up over a large project. However, the quality may not be there.

    There is also a difference between using a freelancer versus an agency. Agencies have a lot more overheads to cover, which makes them more expensive, but they usually have better coverage of the end-to-end process, because they have staff to address all of the skill sets needed to build software.

    Another element is the experience of the developer. As expected, if you use someone with lots of experience, it’s going to cost a lot more than if you have an inexperienced one. The balancing act between cost and experience is a tough one. Depending on your budget, it may be worth the risk to give someone less experienced a chance. However, if you don’t have a lot of time to spend on the project, then you’ll need someone more experienced.

    3. How it will be built

    If you’re building a mobile app, then the question of native vs hybrid will often be raised. Native apps are built individually for each phone operating system (e.g. iOS vs Android), and in the language of those operating systems. On the other hand, a hybrid app will be built once, and then converted into apps for different operating systems. The former is much more expensive because you have to build the app multiple times, but it allows you to have a product that is made specifically for that operating system. Hybrid apps work well too – and are often a good starting point – but you have to compromise because you’re building a “one-size-fits-all” product.

    On the web side, there are lots of ways to build a platform. You can use existing platforms like Wordpress to build very functional and experience-rich applications. Or you can build from scratch. This approach can have varying costs too depending on what you want.  If you can leverage an existing platform, it’s probably going to be cheaper than building from scratch. However, down the line, you might have to replace it with something else that allows you to do all the things that you might want to do.

    4.What devices need to be supported

    The number of devices that you want to run your product on will also affect the cost. If you’re only looking at a platform that someone will use on a laptop or desktop, that’s a different proposition to having it work on all device types. Just dealing with multiple screen types adds lots of overheads. Think about the different sizes of mobile screens and you’ll start getting an idea of the effort involved. Even if your product is built to be responsive, you still have to test it on all of these devices to make sure it works as expected. If you want to support touch screens, then there’s even more stuff to design, build and test. A lot more work has to go into making your product work on multiple devices, than making it work on one.

    How much will your project cost?

    Hopefully, you’ve now got a better feel of some of the major things that affect the cost of a software project. There isn’t a standard number that someone can give you.  If you want to know how much you need to budget for, then you really need to talk to a few developers about your specific idea. They should be able to give you can indication of the cost. You also need to find out how different parts of your idea will affect the cost, and where you might be able to simplify things or reduce what you build. This might affect the viability of your idea.

    At the end of the day, you need to know what it’s going to cost to make your idea a reality. This also includes all of the other costs that you’ll incur to launch your product. To give yourself the best chance at success, make sure your budget can cover it all.

    Looking for a developer?
    Get my 10 Essential Tips for hiring the right developer for your project.
    Download it now for free!
  • Why should you build a prototype?

    Why should you build a prototype?

    Prototyping is a common approach for developing a mock or sample product to help test concepts before building out the real thing. It’s used in all different industries and can come in all shapes and forms.

    In this article, I’ll look at what a prototype looks like for online platforms and apps, and how it can help you build a better product.

    What is a prototype?

    A prototype is anything that represents your future product to a user. Traditionally, in manufacturing, this might have been a sample of a piece of clothing or something cobbled together to show how the product might work.

    Today, when it comes to platforms and apps, the approach is the same. You want to build something that represents your future product without actually building the whole thingdf.

    As software isn’t a physical product that you can create a sample of, the most popular way to prototype is to create something called a clickable prototype.

    What is a clickable prototype?

    A clickable prototype is a collection of medium or high-fidelity wireframes that represent what a customer might need to do to complete a task. These wireframes are put into a computer, where you add some ‘buttons’ and ‘links’ that allow people to navigate through your prototype.

    There are prototyping applications you can use, such as InVision, Balsamiq, and Acrobat XD, that provide a set of tools to help you build and get feedback on your prototype. You can also use something like PowerPoint or Keynote. Even some hand drawn pictures can work as well.  The video below gives you an example of what a prototype looks like.

    The main idea is that people have something to see and ‘hold’ in order to better understand what you want to do.

    So, when do you do all of this?!

    There are two main areas where you can use prototypes:

    1. Validate an idea
    2. Test your design

    1. Validate an idea

    If you find your idea is hard to explain to potential customers and users, then a prototype is a one way to illustrate what your platform or app will do. By building a prototype, you can get feedback on your idea, and get input into what you need to include in your product. You might find some features are more important than others, which might change the way you prioritise your app’s development.

    2. Test your design

    Prototypes are also good at testing your product’s user experience. The prototype represents how your users will navigate through your system. You want to find out which parts are easy to use, and which aren’t. By getting people to play with your prototype, you can identify how well the solution addresses their problems based on its usability.

    Why would you prototype?

    If used correctly, prototyping will give you a more informed idea of what you should be building, so that you can get people to use it. Prototyping will also allow you to build a better product, so that the people using it will keep using it.

    Ultimately, both of these things reduce the risk of you spending money unnecessarily. If you can’t build the prototype yourself, it will cost you some money. However, spending a small amount of money to discover you’re building the wrong thing is way better than spending months, and a lot more money building something that isn’t what you need.

    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.
  • What are acceptance criteria?

    What are acceptance criteria?

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

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

    What are acceptance criteria?

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

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

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

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

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

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

    Examples of acceptance criteria

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

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

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

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

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

    How do you use them?

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

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

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

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

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

    What does CRUD mean?

    When you have an idea for a platform or app, you might start paying closer attention to ones you use today, or new ones that do similar things to what you want to do. What you might notice is that there are some common things that you do in each of them. If you’ve added something, viewed a list of things; maybe even updated or deleted something, then you’ve performed a CRUD operation. In this article, I’ll explain what they are and why you need to know about them.

    What does CRUD stand for?

    CRUD stands for Create, Read, Update, and Delete. These words refer to some very common things that you do on a daily basis. You add (or create) a post for Facebook. Then you view (or read) other people’s posts. Maybe you edit (or update) an image in Canva, or delete one that you don’t like. If you start thinking about your interactions with different platforms and apps, you’ll find these are functions that are common to them all.

    Seems simple enough, how do you use them?

    Understanding what CRUD means is most important in the defining what you want your product to do. It relates to what the users in your platform or app should be able to do. As you think about the different processes that your users will go through to achieve their goals or solve their problems, you should also think about what CRUD operations they should be able to do.

    It might seem simple to say – “oh yeah, they should be able to do all of those things”, but sometimes, it doesn’t end up that way. Maybe some users should be able to do all four things, but other users should only be able to view. What happens if you update a master list? How should the updates be distributed to users? What are the implications down the track if a person can delete something? Is it a permanent deletion where it is gone from the system altogether? Or maybe it’s just a case of “hiding’ it from the user to make it appear like it’s been deleted.

    All of a sudden, you now have to start digging deeper into what you want your platform or app to do. For every feature and function, you should be thinking about what your users will be doing, but also what you want them to be able to do. Take some time to ponder all of this, as you’ll find it opens up a lot of complexity in your system that you might not have been aware of before.

    What if you don’t do this?

    The problem is that CRUD operations seem so obvious to people, that they either don’t even think about them.  Alternatively, they subconsciously assume that their developers will build them anyways – because they’re a part of every system they’ve ever used.

    The thing is – developers can only estimate and build based on what’s specifically stated. It’s hard for someone to anticipate everything that’s not written down. If there’s something specific in the way you want your platform or app to work that’s not obvious to someone, then your developer either won’t build it, or they’ll build it in a way that you didn’t want. Who can blame them though? They’re not mind readers, and they’re running a business too – so the only way for someone to deliver to expectations is to have a clear definition of what needs to be built.

    Imagine that you have a five features in your platform or app, and you only define your product with the create and update functions, but not the read and delete ones. All of a sudden, you’ve only covered 50% of what you need. Fast forward a few months, and your developers will be asking for more money!

    So, when you’re looking to turn your idea into a product, consider your CRUD operations. Even though they sound simple, they have a big impact on your development project both in terms of the features that are developed and the overall cost.

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • What’s a process flow (business process flow or workflow) diagram?

    What’s a process flow (business process flow or workflow) diagram?

    A process flow (business flow or workflow) diagram maps out everything that’s required to get from point A to point B. It shows the steps in a process, the users involved, inputs, outputs and decisions. As a result, it’s a very powerful tool to illustrate what you want your online platform or app to do.

    In this article, I’ll explain the different parts of a process flow diagram, show you an example, and tell you why you should use them to describe what you want your product to do.

    Parts of a process flow diagram

    A process flow diagram consists primarily of 6 parts:

    1. Start and end points: these are points where the process starts and ends.
    2. Steps: these are the individual activities for taking a user from the start point to the end point.
    3. Users (and systems): these are all of the people and applications involved in the process.
    4. Inputs: these are all of the things that need to be contributed to the process to complete the task. This might be information, documents, images or anything else that is required.
    5. Outputs: this is anything that comes out of the process. It can be physical (like a document) or digital (like a search result list or an online message to confirm payment) or maybe its emotional (like the satisfaction of finishing a game)
    6. Decisions: these are all of the choices that need to be made by a user to get from the start point to the end point. They may also be conditions that result in a user being diverted in a different direction.

    All of these parts join together to create your process flow diagram.

    Examples of process flow diagrams

    Now, I’ll show you how all of those pieces fit together to create a process flow diagram.  This example is for subscribing to a newsletter.

    A couple of things to note here. Firstly, there are lots of different ways to draw this diagram. It doesn’t matter which one you use – in fact, it doesn’t matter if you follow the rules and syntax at all – as long as your developers and any other people involved in your project interpret your diagram correctly.

    Secondly, some processes have steps that could have many steps within them – you could very easily go down two or three levels as you flush out what happens in a step. However, like writing your requirements, there’s an art to figuring out the level of detail that you should go to. At some point, the effort required to create the diagram outweighs the benefit. You might eventually need to get down to that level of detail to build your platform or app, but when describing what your product should do, it’s probably not necessary.

    Why process flow diagrams are important

    While process flow diagrams can be used to map out anything that people do (e.g. call centre operations, consulting engagements, opening a bank account, etc), they are particularly  powerful when developing online platforms and mobile apps. Along with wireframes, they help to illustrate your vision to the people that will help you bring it to life. These diagrams represent a language that developers can understand and they show key concepts – without having to do a lot of writing.

    Process flow diagrams also help you to flush out your product. Platforms and apps have a lot of moving parts, so if you can identify all of the processes in your product, you’ll get a good idea of what needs to be built. From there, you can expand on each process to  define what you want your product to do.

    Finally, using process flow diagrams will give you a more complete picture of your platform or app, and puts context around your product requirements. With more information, your developer is now in a better position to give you a more accurate estimate for building your product.

    Want to learn more tools and skills to help you define your product for a developer?
    Check out our Requirements Writing course.
  • Why you need to focus on “what” not “how” (when defining your product)

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

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

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

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

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

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

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

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

    What’s the difference between the two examples?

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

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

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

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

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

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

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

    Wrapping up…

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

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

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

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

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

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

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

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

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

    1. Understand the process

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

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

    2. Learn how to brief your developers

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

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

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

    3. Know what to build

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

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

    4. Keep on top of your development project

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

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

    5. Don’t forget the biz

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

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

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

    The bottom line

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

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

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

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • Why words like ‘easy’ and ‘quickly’ don’t belong in requirements

    Why words like ‘easy’ and ‘quickly’ don’t belong in requirements

    So, you’ve got an idea for website or mobile app that you’re really excited about, and you’re ready to define what it should do. The first thing that pops into your mind might be something like, “the app should be easy to use”. Not an unreasonable thought. However, ease of use is how you market your platform or app – not how you get it built.  Words like ‘easy’ or ‘quick’ should not appear in the brief you provide to developers. Let me tell you why.

    A dictionary definition of easy is, “not difficult to do, not needing much work”.  Interestingly, this definition doesn’t tell me what easy is – it’s just telling me what “easy” isn’t. This is because the word “easy” (like the word  “difficult”) fall into a category called “vague” words.  

    The same dictionary tells that the definition of vague is “not clearly or fully explained”), and that’s really the crux of this article. You cannot be vague when defining what your product should do.

    What other words should you avoid using?

    There are many words used in everyday speech that fall into the “vague” category. Big, small, large, little, simple, quickly, very, many and lots are all words that shouldn’t be used to describe what you want your product to do. The problem is that each of us places a different expectation on a particular word.

    Take the word “big” as an example. How big is big? Compared with a mouse a sheep is big; compared with a sheep a horse is big; compared with a horse an elephant is big. It’s only when someone else delivers their version that you might realise the chasm between their expectations and yours.

    What happens if your requirements are vague

    If you define your product without a clear and fully explained description, there are three likely outcomes:

    1. You will not get an accurate estimate for how much it will cost to build your platform or app. If your developer has to make a lot of assumptions about what your vague words actually mean, then they may over (or worse!), under-quote you.
    2. Your developer won’t build what you’ve pictured, what you need and what you expect. You ordered a horse, but they delivered an elephant.
    3. You and your developers will find it hard to determine when your requirement has actually been addressed by the solution. What I mean here is that when you go to test your product, how will you measure whether it is ‘easy to use’ or whether a screen loads ‘quickly’? What are the parameters? And hence, how will you objectively determine that your platform or app is doing what you asked for?

    The end result is a lot of frustration and, even worse, a project that costs you more money, and takes more time to complete than you ever planned for.

    I reached out to my favourite copywriter and PR guru, Emma Edwards from Write Now PR to explain why vagueness causes problems in communicating what you want. “Assertive, precise language – using concrete terms – gives everyone a comfortable framework.” Emma says, “No confusion, no complication.

    “Often we say that we want something to be ‘like’ or perhaps ‘better’ than another. For a developer, who deals in detail, words like that are as useful as telling your mechanic that the model of your car is silver. It doesn’t give them a clear reference point, and ultimately exposes you (and your project) to an entirely subjective response.”

    So, what can you do to avoid vagueness in your requirements?

    Emma suggests the following, “Precision is essential. That means you need to think more deeply about the words you use than any of us tend to do in day-to-day life. Think of yourself as that wine connoisseur detecting woody notes and undertones of a freshly opened can of tennis balls – you want to think deeply, and articulate painstakingly what you envisage and expect from your platform or app.

    “Use language that cannot be misunderstood and which conveys certainty. If something *must* be a particular way, then state that. Because there is a big difference between ‘I would like’ and ‘it must’. Instead of ‘a few’, ‘a couple of’, ‘around’, etc., state an actual number. Don’t ask for it to be ‘better’ than Facebook – show and tell people what that looks like.

    “The message that vague, fluffy language sends is that you’re actually not clear on the detail. And if that IS the case, you need to go back to the drawing board.”

    What does specificity look like?

    It’s actually not that ‘easy’ to avoid vague words. The main thing is to dedicate the time to think about what you want your product to do in detail. If you are clear on what your platform or app should do, the need for vague words goes away.

    Some examples of specificity include – “I want the screens to load within 2 seconds” and “The user should be able to complete the process in less than 5 minutes”.  However, you might not always know what the specific piece is. Sometimes, that’s ok – it can come out later in the process. If you’re aware of where the vagueness is, you can highlight that to your developer.

    Defining your product is full of pitfalls and considerations like this. It’s essential for you take the time to understand what you need to do and what’s expected, in order to set yourself up for success.

    Need some help defining your product so that your developer understands what you want?
    Check out our requirements writing course.