Great Products Consulting

Author: Great Products Consulting

  • 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.
  • What’s the difference between Web Design and Web Development?

    What’s the difference between Web Design and Web Development?

    Do you know the difference between web design and web development? I often see people looking for recommendations for one or the other, but did you know that when you’re building an online platform or mobile app, you might actually need both?

    Traditionally, these two disciplines were quite separate and distinct. However, over the years, the line between the two has been blurred.  In this article, I’ll talk about both of these terms, and how they might impact your product development project.

    Web Design

    As it implies, web design primarily looks at how the site will look. Think colours, fonts, images – the general look and feel. It also considers the usability of the site. However, web design is now also so much more – which is where the confusion occurs.

    Web designers can also build websites. This often includes the marketing-focused websites that we all use for our businesses. The ones that explain who we are and what we do – these are called “static websites”. They can do this with the help of website platforms (or content management systems) like Wordpress and Squarespace, which usually have drag and drop website builders. These are further enhanced by “themes” that are essentially templates of “pre-built” websites. These allow designers to use their design skills to craft a web page for you.

    To even further extend the power of web designers, are “plug-ins” or “apps” that are essentially pre-built tools, which interact with the website to give it extra functionality. They allow you collect email addresses, and send them to your email marketing or CRM tool. They can also be as sophisticated as allowing you to have a membership section or accepting payments.

    A good web designer will also have some SEO skills as well. As a marketing tool, your static website should be easy to find through search-engines.

    Web Development

    Even with the increase in the scope of work that a web designer can cover, there are still limitations to what they can do – unless they really learn how to code. While most web designers will be able to do some front-end coding (using HTML and CSS), these programming languages focus on how things look on the screen. In order to do more complex things – you need a web developer. 

    Web developers have a different skill set. They can build a much more dynamic website that can capture information, store it, and do something with it. Developers can build applications that allow you to move and manipulate objects. All of the website builders, themes and plugins were built by developers.  This means that web developers are in a much better position to build a more specialised platform; with unique or specific features.

    Why do you need both?

    As you can see web designers and web developers do very different things. While they can both build you a website, it depends on what kind of website you want.    

    While a web developer can build you a static website, it might not look very good. This is not what developers are good at. However, if you want to introduce automation to your business, or to extend your business offerings through an online platform, then a developer is more likely to be able to help you.

    If you’re building a new online platform that you want to market and sell as a product, then you’ll probably need both. A web developer will build your platform – with all of the screens and components that you need to give you the features that you want. Meanwhile, the web designer will create the static website that you need to market your platform.

    But there’s more…

    Unless your web developer has some interface design (UI) and user experiences (UX) skills, you’ll also need one or more people to make your platform look nice, and to make it user-friendly. While, a web designer might be able to create a visual design for your platform, they may not have the skills and experience needed to design the user experience.

    The next time you’re thinking about who you need to turn your idea into a product, along with UI and UX designers – consider both web designers and web developers.  If you’re very lucky, you might find a superstar that has all of the skills outlined in this article! 

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

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

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

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

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

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

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

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

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

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

    What’s the difference between the two examples?

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

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

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

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

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

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

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

    Wrapping up…

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

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

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

    Need some help defining your product so that your developer understands what you want?
    Check out our requirements writing course.
  • What you need to do to manage your development project

    What you need to do to manage your development project

    Regardless of what work you’re outsourcing to someone else to do, people often forget that you can’t just dump it on someone’s desk or inbox, and walk away. This is especially true when you’re getting someone to build you an online platform or mobile app. Since the building of your product is the most important part of getting it to market, it’s critical that you make the time to manage your development project.

    What’s does it mean to “manage” your project?

    At its most fundamental level, managing your project means that you have to keep an eye on what’s going on. It seems obvious, but most people don’t look beyond the basics of schedule and budget, which means they miss out on a whole lot of important stuff.

    Here are 5 key things that you should be managing:

    1. Cost
    2. Schedule
    3. Scope
    4. Risks
    5. Issues

    1. Cost

    Cost is how much you’re spending on your product development project. Yes, it’s probably the main thing that you want to track. Most people have fixed price contracts (i.e. a set price to do all of the work), which means that they only think about costs when their developers ask for more money. Regardless, of your contract, you should keep a close eye on your costs. The more money you spend upfront, the more you have to sell to pay off your investment.

    2. Schedule

    Time is another important part of your project. You want to have a clear view of when your developers will be giving you stuff (Hint: It should be in your contract.) If there are delays in completing development, then it will take you longer to get to launch, and you’re waiting longer to start making money.  Make sure you’re seeing progress in your project.

    3. Scope

    Scope is about building the things that were agreed to. You want to make sure that you’re getting what you asked for. Scope creep is one thing that’s really common in development projects.  It can cause your costs and timelines to blow out considerably. Scope also covers quality – developers may build what you want, but it might not work properly – and that’s not good either!

    4. Risks

    Risks are basically anything that might affect the outcome of your project. They come in all different flavours and can be in your control, and out of your control. Some examples of risk include regulatory risk, technology risk, legal risk, resourcing risk, financial risk – pretty much anything can be a risk. You want to have an idea of all of the key risks that might derail your project, and have a plan for mitigating them.

    5. Issues

    Issues are things that are raised, and need to be addressed during the course of your project. These generally are related to things that aren’t working as they should, or things that need to be resolved to complete a development project. For example, an issue might be that a button doesn’t work on a screen, or maybe your developers can’t get your website running on your host. You need to track and manage your issues to ensure that your project can finish successfully. You may not solve everything prior to your launch, but the important items will be fixed.

    In summary…

    Cost, schedule and scope are all tied together. If you increase the scope, it will cost you more, and take longer to build. Alternatively, if you’re behind schedule, you may need to get more people working on your project, which increases costs – or you can reduce how much you build. Finally, if you’re going too far over budget, you can reduce what gets built.

    Risks and issues run alongside of the other three. They can relate to any of the three issues, and to other things in and beyond your control.

    As the person that’s paying a lot of money for a developer, you have a very strong interest in seeing your product development project complete successfully. By having an awareness of these five factors for managing projects, you’ll be able to track and monitor how well things are going. More importantly, you have a head start when (not if) things go wrong.

    Want more tips on how to turn your idea into a great product?
    Read our Foundations for Non-Tech article.
  • 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.
  • What’s the Difference between UI and UX?

    What’s the Difference between UI and UX?

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

    User Interface (UI)

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

    User experience (UX)

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

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

    Great UI does not always mean great UX

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

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

    But there are overlaps too…

    Let’s take a button as an example. 

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

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

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

    Why you need to know the difference between UI and UX

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

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

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

    How much detail do you need? (writing requirements)

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

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

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

    How do you end up this way?!

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

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

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

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

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

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

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

    Why should you care?

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

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

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

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

    Features vs Benefits (define your product based on benefits)

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

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

    Define your product based on benefits

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

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

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

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

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

    Build the right product

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

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

    Wrap up…

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

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

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

    How your pricing model affects the development of your product?

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

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

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

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

    One-off upgrades

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

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

    Access to features on an ongoing basis

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

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

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

    User and usage limits

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

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

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

    Marketplaces and directories

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

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

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

    Non-standard pricing, discounts and introductory pricing.

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

    Wrapping up…

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

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