Great Products Consulting

Author: Great Products Consulting

  • What’s in a web application?

    What’s in a web application?

    You have an idea for a web application (a.k.a app or platform), but what does that actually look like? If you think about building a house, you have a foundation, a frame, walls, a roof, plumbing and electrical wiring.  All of these things are important to the finished product.  You should think about your application in the same way.  It’s made up of a bunch of different components.  Depending on the type of application, these components will be needed to make your product work.

    Since, I’m always trying to find ways to explain technical concepts to people with non-technical backgrounds, this article is going to take you through the components of your future product.  This will help you to understand what you’re aiming to build. Mobile apps are slightly different, so I’ll look at that in another article.

     Here’s a simplified diagram of your web app:

    As I started to create this diagram, I realised that there were a lot of things we just take for granted. We turn on our phones, open up a web browser, go to a website and it all just works. It’s obviously a little more complicated than that! So, when I say a “simplified” diagram, it really is! For now though, it’ll suit my purpose for explaining some basic concepts to you.

    Some of these explanations may sound obvious, but for the sake of making sure that everyone is on the same page, please bear with me.  

    Device (hardware and software)

    Let’s start at the top of the diagram. The device (your phone or computer) is a physical piece of equipment through which you access your application. This is called “hardware”. When you turn on your phone or your computer, the thing that makes it work is called “software”. Without software, you phone is like a paperweight – it does nothing! The software associated with making the hardware work is called “operating system” (or O/S) software. The individual programs and apps that allow you to do things on your phone or computer (e.g. a web browser) are also called “software” or “applications”.

    Software is a collection of programs that provides instructions to do something and it can be written in many different coding languages. Programs themselves are a collection code used to perform a function. The code uses specific terms and formats to instruct the device on what to do – this is dictated by the coding language chosen. I’ll save a review of different programming languages for a different post as there’s a lot to cover there.

    Front-End

    The “front-end” is composed of all of the things that you see on the screen. It also includes some smarts to help you navigate the app, capture information and trigger activities within your app.

    The level of complexity on your front-end will depend on the types of things that will done via the screens. For example, if you’re just displaying information that never changes, then that’s a lot easier than a page showing search results on a map; where you can zoom in and out on the map, select an object and view information about it.

    Back-End

    The “back-end” refers collectively to the programs and data storage for an application.

    Back-end Programs

    Back-end programs do the heavy lifting – they allow you to do things like store and retrieve information, make decisions, and perform actions by applying logic to information provided by the front-end. Think of it as the engine behind what you end up seeing on a screen when you make a request for something.

     Some examples of back-end programs include:

    • Creating an new user account
    • Validating a login request
    • Retrieving a list of items based on search criteria
    • Calculating values for a report
    • Making a decision on a customer appliction

     As you can see, the back-end is just as important as the front-end. Together, they work with some sort of data storage facility to make your app work.

    Data storage (a.k.a. a database)

    Information that is captured by your app needs to be stored somewhere so that it can later be retrieved, displayed or processed at a later date. This prevents a person from having to re-enter information over and over again. The data held in the database can also be generated by the app itself. This might include things like the date the information was entered or an internal status for a person’s account.

    For web apps, data is usually stored in a centralised database where the information for your app and all of your users is held in a single place.

    There are alternatives to a “database” which is why I have termed this “data storage”. For now, the important thing to know is that data for your app will be stored somewhere and programs will be written to access and update it.

    Application Programming Interface (API)

    So how do the front-end and the back-end talk to each other? This is where APIs come in. An “application programming interface” is a program that allows two applications to talk to each other. Those applications may belong to you or to someone else.  APIs take a request from one application and provide it to another application to process. It also provides the response back to the original application. In your case, this conversation will mostly take place over the Internet.    

    Some APIs are standard – for example if you want to embed a Google map into your app or if you want to add email addresses to a MailChimp list. This allows companies to establish consistent methods for applications wanting to communicate with them. Think of them as a published manual with the available ways to contact an application and the functions you can access. This manual will also tell you how to make the request and the format that is required.

    Other APIs, like your application, may require some customised coding to work. However, for most functions, there’s probably already a template that your developers can start with to achieve the required result.

    Host (hardware and software)

    Your app (front-end, back-end and datastore) has to be loaded onto a piece of hardware to work. Otherwise, they are just letters and numbers on a page. That piece of hardware is called a “server”. It’s a physical device that has the capacity to run programs, manage all of the requests being sent to it, and store data. These machines can range in size and the specifications will depend on the needs of the application and the number of people accessing it. These servers also have software that allow you to monitor their performance and manage the content on them (think uploading and downloading files and programs, and managing security).

    As you can imagine, at the beginning, most of us will not be buying and running our own servers, so we’ll use companies that specialise in this. These companies are called “hosts”. They offer services, called “hosting” that provide the hardware (e.g. servers) and the software to run your app.

    Hosting and choosing a hosting service deserves a whole article of its own, so I’ll leave it at that for now. Basically, to make your web app work and to make it available to people, you’ll need a host.

    What does this mean for you?

    So, there you have it – the components of a simplified web application. It turns out there’s a lot there!

    It’s important that you understand all of these different components so that you have a reference point when a developer starts talking about them. It also helps you to know what you’re actually building.  Finally, you now have an idea of the types of expertise that you’re looking for when putting together your development team.    

    If you have any questions or if something about this isn’t clear, please feel to let me know in the comments below.  

    Do you need some help to make your web application a reality? Send us your details and we’ll set you up with 30-minute discovery session to get you on the right track:

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.

  • An intro to defining your product (aka writing requirements)

    An intro to defining your product (aka writing requirements)

    In my last post, I talked about how people often have trouble briefing their developers and specifying what they want their app to do. This week, I thought I’d share the basics of defining your web platform or mobile app. In “biz” speak, this is really your product definition and in “tech” speak, these are called “business requirements” and they represent a documented version of your product and what you want a developer to build.

    Defining your product (aka writing requirements) for apps is actually a skill. It takes practice to think about what your product should do and how to explain it to someone. You need to translate your high-level idea into something concrete and tangible so that it instructs a developer on what you want.  

    As the person that has the idea and the person that owns the business, you’re going to need to know your product inside and out. I’ve found that this is often a hard thing for newcomers, as they don’t know to drill down to that next level of detail.  

    There are a few steps to creating a full set of requirements for your product, which will take a while to explain (I’ve identified eight of them in my requirements writing course). So in this post, I’m going to jump straight the end to show you what a requirements looks like. This is what you want to get to.

    Need help with defining the requirements for your web or mobile app? Fill in the form below for a free 30-minute discovery call:

    High-Level Requirements

    If offering a solution (your app) to a person is all about solving their problems or helping them to achieve their goals (more on this another time), then when you define your product, you need to focus on three things:

    1. What is it that you want someone to do?
    2. Who is going to be doing this “thing”?
    3. Why will they want to do it?

    A “user story” is a handy way of pulling this all together in a single sentence:

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

    This amazing sentence is called a “high-level requirement”. It’s giving the reader an overview of a specific thing (or “function”) that needs to be supported in your app.

    Seems simple right?! Well, here’s where it gets a bit complicated. Your user story could include a very big activity – in which case, you’ll want to break your user story down into a bunch of little user stories. For example, imagine you were building a travel-booking website, one of your user stories might be:

    As a manager, I want to be able to view reports, so that I can manage my business.

    This user story covers quite a lot of ground – what reports do you want to view? What do you need to manage in your business? From this user story, you might actually create some other, more detailed, user stories:

    As a manager, I want to be able to view a booking report by property, so that I can see how many rooms have been booked for a property and make decisions about pricing.
    As a manager, I want to be able to view a report on total revenue by property, so that I can identify low performing properties to investigate.

    Can you notice the difference between the first user story and the next two? Look at how specific the second two are. Writing requirements this way forces you to be as descriptive as possible and also to think about what you really want.

    The important thing here is to make sure you’ve covered the whole breadth of what you want your product to do. If you miss something here, it may end up costing you more money, as what you ask the developer to do all of a sudden becomes a lot larger.

    As I mentioned in my tips article the other week, try and keep your product as small as possible. This will reduce the complexity in your project and ultimately the cost and time it takes to build. It’s always easier to improve on something that has already been built.

    And there’s more!

    Your requirements aren’t done yet! From your high-level requirement, you need to break it down even further into detailed requirements. This means that you need to provide a bit more information about it. The kinds of things that you need to consider are:

    • What data do you want to capture, store or retrieve?
    • How will users complete a particular tasks?
    • What are your users trying to accomplish? 
    • Are there different scenarios that might occur as a task is being performed?
    • What are some of the assumptions, prerequisites and dependencies that apply to the task?
    • Are there different rules that should be applied by the app?
    • Will there be things that you might want the app to do in the future?

     If you take our reporting examples, some of the detail might include the fields that you want to see on the report. Other things that you might consider are:

    • How do you want the data to be sorted?
    • Do you want to be able to filter the data? (e.g. by type of room? by date range?)
    • Do you want to see an average price across all bookings? Maybe by room type?
    • What other information do you want to see? (e.g. how many rooms have not been sold?)

    In addition to the user story above, the detailed requirement for the booking report by property might also say:

    The report should include a list of all properties available on the site.

    It should include the following fields: country, city, property name, property address, booking date, total rooms allocated by rate and by type, total rooms booked by rate and by type, and total rooms not booked by rate and by type.

    The data should be sorted by country.

    The user should be able to filter the report by country and by city.

    These are the kinds of things that you’ll want to think about and document. You have to do this for every high-level requirement that you have, so there will be a lot to do!

    The key is to get you really thinking about what you want. Don’t worry about getting all the detail down in the first pass. There’s a good chance that as you write one requirement, you’ll remember something for another requirement. You may create, combine or delete high-level requirements as you flush out the detailed ones. In the whole process of defining your product, you’ll probably go back and forth several times until you feel like you’ve got it all sussed out. You want your requirements to be as complete as they can be, but chances are you’ll miss some of the details. That’s ok too as your developers should pick them up when they review your requirements.  

    And there’s more!

    As you can see, it takes quite a lot of work to define your product. Even if your app will only have one or two functions, you still need to have a detailed understanding of what you want your product to do. As the person that owns the idea, people will look to you for guidance. The clearer that you can be about your product, the easier it will be to develop your app.

     So, to summarise – in order to define your product, you have to write both high-level and detailed requirements for each of the things that you want your app to do. These requirements will inform your developers on what you want to build. It’s important for you to have a detailed view of your product to ensure its success.  

    There are some more tips on writing requirements in my article the other week, so if you haven’t read that one, head over there now to check it out.

    Help! I need to discuss strategies for defining my product! Fill in the form below for a free 30-minute discovery call:

    NOTE: for those of you that understand what agile is, I understand that some of the detail would normally get flushed out during a sprint. However, I feel that people new to building apps should take the time to write detailed requirements upfront so that they can better understanding what their product will do and so that they can appreciate all of the decisions that need to be made to build it.    

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.

  • Telling a developer what you want your app to do (challenges and strategies)

    Telling a developer what you want your app to do (challenges and strategies)

    A common challenge of non-technical people building web platforms or mobile apps is that they struggle with how to tell a developer what they want. Defining your product is part of the requirements writing activities in the software development process and it’s an important part of building your app.

    Imagine you describe a feature to your developer and when it’s ready, it doesn’t do what you want it to.  Sound familiar? It’s actually not uncommon for this to happen. So, in this article, I’ll explore why this is the case and provide some strategies for overcoming it.

    A different skill…

    Explaining and describing things is a skill and so is writing. These are skills that we all have – most people have written an email or told a story. However, it can be a lot harder when you’re trying to articulate what you want your product to do.

    Imagine you want to buy a house and you’ve engaged a real estate agent to find you one. When asked what you want, you might say that you want to live in a particular area and you might mention the number of bedrooms and bathrooms that you’re looking for and may be a price range. The agent finds you a bunch of houses and you go and look at them. You then realise that you forgot to mention that you want a single-storey house and that it should be detached and have a pool and a lockup garage, etc. The real estate agent comes back with another list of properties – and you realise again that there are some more things that you want.

     This example illustrates what happens in app development projects all of the time! People are constantly adding to their list of “wants” and all of a sudden, the project takes longer and costs more than you anticipated.

    Have you also noticed that we very rarely talk about what we want in life at a detailed level? When we’re asked to do it, it can take us a while to come up with a really good answer. It takes even longer if we’re asked why we want what we want. When we’re documenting what we want our product to do, we’re doing just this – and if we haven’t practiced this skill, then it takes a lot more time and effort to do and we might not be able to do it very accurately.    

    A different audience…

    There are a lot of people that write for a living – newspaper journalist, author, screenwriter, songwriter, technical writer, website content writer, etc. All of these people fundamentally do the same thing, but they write different content and for different audiences.

    Telling a developer what you want works the same way – which means you have to write for your audience. 

    It feels like it should be easy – but it isn’t. Developers generally have minds that work a bit differently – and so they should. It’s what allows them to do the great things that they do. It also means, that if you don’t tailor your content in a way that a developer understands, it’ll be a lot harder to end up with the product that you want.

    Different content…

    The final reason as to why it’s so hard to tell a developer what you want is that you’ve probably never have had to talk about this kind of stuff with anyone before! Building an app is likely a new experience, so you might not realise that there are some things that you were meant to tell your developer.

    For instance, did you know that you have to tell your developer your expectations for how many people will use the app? How quickly you think your platform will grow, etc.? What information do you want to collect in a form? What kinds of reports do you want? What fields should display on those reports? These are the kinds of things that you probably don’t think about when you’re defining your product.  

    Like any profession, developers come in different forms – some are purely coders and follow instructions to the “T”. This is where the level of detail in your content is very important. You can also get developers that are a bit more adaptable and will ask questions for clarification. However, you still need to give them enough content so they can understand what you’re trying to do. Remember, any time they have to clarify something, that’s time taken away from coding your app.

    Strategies…

    So, with all of these things working against you, how do you effectively tell a developer what you want?

    Learn the skill:

    Defining your product and what you want it to do is a skill. In apps and software development, it’s actually quite a specific and difficult one. There are people that get paid 6-figure salaries in large organization to do this. I know this, because I was one of them! So, how do you learn this skill without years and years of experience?

    First start by understanding what information you need to provide and how to structure it. You can look for some examples of how others have done this before (search for “good business requirement examples”). Model your own writing after these examples – and then keep going. Odds are the examples that you find are going to be high-level ones, so you need to dive a bit deeper to get the level of detail that you need for your app.        

    Know your audience:

    Developers are coding programs for a computer to interpret so start to think like a developer. How you describe your product to a developer is going to be very different to how you might describe your product to a potential customer, so adjust accordingly.  

    Start by being logical and systematic in what you write. Use “if this, then that” language to describe how someone will interact with the app and how decisions should be made. Write in bullet points and avoid long paragraphs. Draw diagrams to illustrate concepts. Find examples of existing apps that can illustrate what you want your app to do.

    Write it down:

    Basically, if you want your product to do something, then you’re going to have to document it for your developer. They can’t guess what you want – and if they did, chances are, it wouldn’t be the same as what you imagined. Think about your experience with an online tool or app – what happens normally? What happens when something goes wrong? If you want the field on a form to be a drop down, then you’re going to have to state that in your requirements.

    To make sure you have the right content, think about all of the processes required to make your product work. Think about all of the people that will use your app and how they will use it – I’m talking about all of the support functions that will be needed to run your app too. Also, spend some time thinking about the detail – use workflow diagrams to map your person’s journey and then consider, in detail, what happens at each step.

    Building an app for the first time is quite a feat. There is a LOT involved – and you have to tell that developer exactly what you want. It’s a very good bet that if you don’t, you’ll end up with something you didn’t want. That’s just human nature – we make assumptions based on what we know – but those assumptions may be different from someone else. So, if all else fails, write it down!

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

    If you haven’t guessed already, I’m pretty passionate about this kind of stuff. Web platforms and mobile apps get built all of the time, so people have found a way to get past these challenges! But how much time did it take and how much did they have to spend?!

    My aim though is to get you to the other side without wasting time and money having to clarify what you want or extending your project because there were things that you forgot to include. I hope my strategies will make it easier for you to tell a developer about what you want them to build.

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.

  • Tips for building a web platform or mobile app

    Tips for building a web platform or mobile app

    Curious about how to get your web platform or mobile app developed?  There’s a lot to figure out and sometimes it helps to get a few pointers on what to look out for.  So, in order to get you going in the right direction, I wanted to share with you some tips to help you successfully complete your app-building project and to set yourself up for running an app business.

    Building products and businesses are complex at the best of times – there are lots of moving parts, so you want to arm yourself with as much information as you can. These tips will give you a glimpse into the kinds of things that you’ll have to think about to get your app built and launched.

    Here are my 10 tips for building a web or mobile app:
    1. Validate, validate, validate:  How you do you know if your idea is “great”? Is this the idea that you should be building? You can save yourself lots of time and money by evaluating your idea and deciding whether it should be built in the first place.  See last’s week’s article on ways you can start to validate your idea.
    2. Learn how software development works: If creating a web or mobile app is new for you, then you need to learn more about how they get built. There’s actually a process for doing this – called the software development lifecycle. You should find out, at a high- level, what activities and outputs are involved in this process. This will make it easier to communicate with your developers and you’ll know what you need to do and what happens next.
    3. Start small: Think of the most bare bones version of your product and build that first. You want to make sure that your product really solves your customer’s needs, wants or goals. Starting small means that you don’t spend lots of money when you don’t need to. You can get something tangible built in a shorter amount of time. You may not be able to launch this product, but it will give you something to build upon. It’s always easier to build on something that has already been built than trying to build everything upfront.
    4. Define your product in a way that a developer can understand: You may think your developer knows what you want them to build – think again. The brain of a developer is wired differently from yours – it’s what enables them to do what they do! Unfortunately, this means that you might end up with a product that doesn’t do what you want it to. Developers expect their instructions to come is a certain way, so you need to learn the best way to define your product.
    5. Focus on “what” you want to do rather than “how”: “What” describes the activities and features that your product will provide; the “how” is the design and technical solution that will deliver what you want your product to do. If you provide a “how” to your developer – that is what they will build – even though it may not be the best approach for your product. Once the “what” is nailed down, you can work with your developer to decide on “how”.
    6. Prioritise what you want to build: It can be easy to make everything a high priority – a “must have” for your big launch. The reality is that if you build everything you want, you’ll never launch. You should prioritise based on how much something helps you to achieve your goals and those of your customers and users.
    7. Find a great developer: This is one of the most important factors for a successful project. If you don’t find the right developer for your project, you face an uphill struggle to build your product. You need to find a developer that has as much interest in your product as you do. Check references and find opportunities to “test” them before you hire them. Building trust and a strong relationship with your developer is paramount.
    8. Carefully manage the scope of your project: Scope creep occurs when the size of a project increases after it has started due to improper management of changes for what you want to build. This causes the cost and schedule of your project to blow out. Track any changes that you want to make to the product and have a process in place to evaluate whether it’s really needed.    
    9. Be structured in your testing: Testing is about making sure that your product works as you expected. It’s pretty much guaranteed that it won’t – even with the best developer in the world. A new product is a complex thing and it will have problems. This means that you need to have a structured approach when you test your product.
    10. Plan for what happens after your initial product has been built: Before your product is launched, there are several things that you need to plan for including; getting a copy of your code, defining how changes to the “live” product are managed, backing up and recovering your product if something goes wrong, getting access to any admin passwords and setting up a process for managing issues. Building your product is just the beginning – there’ll be lots to do on an ongoing basis.
    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.
    Any tips to share?

    There you have it. My ten tips for building a web or mobile app. Of course there are many more, but these should get you going if you’re starting from scratch. If you’ve done this before and you’ve got other tips that you’d like to share, please leave them in the comments below.

    * When you download a copy of our cheat sheet, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this download. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.

  • I have an idea for an app – what happens next? (idea validation)

    I have an idea for an app – what happens next? (idea validation)

    Getting a great idea for a new business venture is such an exciting feeling. Finally – you have something that might have legs but you’re still on the fence about what to do with it. It’s such a risk, but can you imagine the life that you might have – the flexibility of being your own boss and hopefully some financial rewards too? If you already run your own business, a new idea may allow you to grow your revenue and allow you to serve more customers.

    For some people, ideas are relatively easy to come by; for others, they struggle with coming up with just one.  However, it’s the ones that require you to build a web platform or mobile app that I’m interested in.

    There are many businesses that people can start and all of them have their complexities – if you want to design and make your own clothes, you’ll have to source fabric and manufacturing. If you want to sell other people’s goods, you’ll need to find those suppliers. If you want to be a consultant or service provider, you’ll have to decide what you want to offer and how you’ll deliver it.

    What makes developing an app particularly troublesome is the cost to build it.  Also, compared to physical goods, it’s not as easy to see a “sample” of your app before you put in the big order, which makes it difficult to know what you’re getting.     

    What should you do?

    If you’ve never been involved in an IT project before, an obvious question once you get your idea is – what do I do next? It’s a very smart question to ask! Before you quit your day job or bet the house on your new venture, let’s take a look at what your next steps should be. 

    If you read my first article on product and software development – you’ll know the answer to this question! 

    After you’ve come up with an idea, you need to analyse or validate it. This is the process of making sure that the idea is the right one to pursue. Making your idea a reality is going to require some investment from you – and it’s not only going to include your time.  More importantly, it’s going to include your money. Therefore, you need to take some time to research your idea to make sure the investment is worth it.

    Idea validation is a necessary step for most businesses, large and small – and it should be no different for you. The last thing you want to do is to spend money on an idea that no one wants. A structured approach to evaluating your idea is key. 

    So, what exactly are you looking for?    

    To get you started, we’ve put together five ways you can validate your idea:
    1. Talk to potential users – use your social media platforms to see if anyone knows anyone who has experienced the situation that you want to solve for, then ask them about their experiences and find out what their issues were. Determine if your product could solve their problems. Alternatively, start with a survey via SurveyMonkey or Typeform to get some feedback about your idea and then interview some of the people that responded.
    2. Look at your potential competition – use a search engine to see if there are any other companies currently doing what you want to do. Determine if what you could offer is at least as good, if not better, than what they do now. Also look at companies that solve the same problem but in a different way. Would you be able to stand out from the competition? 
    3. Look at potential environmental factors that may affect the viability of your business – are there new laws or regulations being proposed? Are there changes in technology? Are people behaving or thinking differently? A lot of new product successes are about timing rather than the product itself – if the world isn’t ready for it, it will be a lot harder to be successful regardless of how good the product is.
    4. Determine the potential size of your market – look for statistics that can give you an indication of the number of people that might experience the problem that you want to solve. What percentage of those people might buy your product?
    5. Think about how much you might charge for your product – would the price be one- off or recurring? Would there be an upsell or downsell? How could you get your customers to buy more from you? How many products would you have to sell to achieve your desired goals?
    What happens next?

    The above will give you an initial view of whether your idea is a good one. Sometimes this is enough for you to make a decision, but more often than not, you’ll have to dig a little deeper to gain the confidence that you need to go ahead with building your app. 

    There are lots of things to look at when validating an idea!  If you work for a large organisation, think about all of the processes that they put in place for spending money on new things.  People have to justify to the company why the idea is the right one to pursue.  

    It’s important to remember that you can’t take the risk out of every investment, but you do want to get enough information to make an informed decision about your idea.  After all, building an app could have a very big impact on your life – good or bad. So, the obvious is question it – why wouldn’t you take the time to validate your idea first?! 

    There are many different things to look at when validating an idea and different ways to do it. If you’ve gone through this process before, please feel free to share what you’ve done in the comments below.

    Want a blueprint for validating your idea?
    My Validation Course will walk you through some key tasks and activities to make sure your idea is worth pursuing
    It’s available now for only $47.

    * When you download a copy of our cheat sheet, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this download. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

  • Intro to Product and Software Development and Product Management (part 4 – launch and beyond)

    Intro to Product and Software Development and Product Management (part 4 – launch and beyond)

    You’ve finally made it! You’re ready to launch your product – but what does that mean? In the last article of this series on product development, software development and product management, I’ll talk about the “Implementation” and “Launch” phases. If you missed the other parts in this series, you can find part one (intro) – here, part two (beginning) – here, and part three (building) – here.

    Product Development

    In the “Launch” phase of product development, you introduce your product to the world. You execute the launch activities that you prepared during the “Develop” phase and your product is now ready for people to use.

     A few weeks after your launch, you should perform a review of your project to see what learnings can be gained. This will allow you to improve your product development processes as you continue to grow and enhance your product. From a product development point of view, you’re done for now and the product management part kicks in.

    Software Development

    “Implementation” is about installing your app wherever it needs to go (e.g. making it available on the App store or Google Play store, installing the code on the host, etc). Your developers will also tidy up their work so that they’re ready for the next project.

    There are situations where you may choose to not make your app available to people right away.  This might happen when you break down a technical project into multiple parts and spread out the delivery over several phases.  Alternatively, you might complete the implementation but delays to your marketing or other launch activities may prevent you from making your app available.

    Once the app has been launched (a.k.a “gone live” or “in production”), your technical team should be around to support it in case something goes wrong. You’ll need to spend some time defining some processes around this so that everyone’s expectations are clear on what needs to be done.

    Product Management

    Finally, the product management component comes into play!  Now that your product has been launched, you start to manage it through its lifecycle. Initially, you focus on the “Introduction” phase.

    Notice that things start slowly – don’t expect a big rush of sales on Day 1! This is where you wear your marketing and sales hats to make people aware of your product and to build their trust in your business. Ideally, you’ll do some prelaunch activities to start the awareness process.  You might leverage your email lists and social media platforms to get your first customers. When you’re a team of one, creating awareness takes time, and often some money, as you don’t have a team of people to help with all of the work.

    After your initial sales, you’ll be monitoring the progress of your marketing and sales activities, getting feedback from customers and looking to get yourself to the “Growth” stage. This (most likely) will include adding more features and functionality to your app. This is where the product development and software development processes kick in again. First, you talk to your customers, watch competitors and research the market to see where changes need to be made (ideation). You then decide which ideas to pursue (analyse). Next, you document what you want build (define and requirements) and you build the changes (develop, design, build and test).  Finally, you make the changes available to your customers (launch and implement). This development cycle is ongoing – so be prepared to continually invest in your product. 

    In the “Growth” phase, you’ll often see a lot of sales without having to invest a lot of money in marketing, sales and new app changes. Eventually though, this high-growth stage ends and you hit the “Maturity” phase where your sales will level out. You can choose to extend the Growth stage by looking for different ways to enhance your product. Alternatively, you can also look at targeting new customer segments or add features and functions that generate revenue from an entirely different source. You may also decide that you don’t want to continue to invest in the product and look to sell it.

    Eventually though, all products make it to Maturity and into “Decline”. Decline is where sales start falling off and your product starts becoming less profitable. During Decline, you look at how to manage your exit from the product and even remove it from the market.

    Wrap Up…

    So there you have it – this is the end of my 4-part series on product development, software development and product management. I hope it’s given you a good overview of what is involved in building a web platform or mobile app.

    Don’t worry if it all sounds a little overwhelming – you’re just getting started! You didn’t just wake up one morning and start walking – it took some time to get there. Think of building your web platform or mobile app in the same way – take it one step and at a time and you’ll find yourself learning as you go.  

    If you have questions about this series, then please leave them in the comments below.

    Don’t miss a post!
    Join our mailing list to get tips and updates via email
  • Intro to Product and Software Development and Product Management (part 3 – build your app)

    Intro to Product and Software Development and Product Management (part 3 – build your app)

    I hope you’re starting to get a feel for what’s required to build an app. I’m now onto part 3 of my series on introducing concepts in product management, product development and software development. In part 1, I provided a general introduction to these concepts and in part 2, I looked at what happens at the beginning. In this post, I’ll cover what it takes to bring your product to life by focusing on the things that are involved in actually building your app.

    Product Development

    In product development, building your app involves “Develop” and “Test” activities:

    “Develop” involves designing and building all of the components required to deliver and run your product. This is the fun stuff! Here, you take all of your requirements (what you want), you find a solution for them (how it works) and then you build it. This should not only include the technical bits for your product (see below under software development), but all of the manual processes required to support your product (e.g. customer servicing, accounting, etc) and the “administrative” things required to run a business (e.g. logos and branding, bank accounts, business registrations, terms and conditions, privacy policy, etc). These non-technical pieces are just as important as building your app – so please don’t forget about them! The develop phase includes planning your testing activities as well.

    “Develop” activities also includes thinking about how you want to launch your product and to whom.  This will allow you to prepare things like content and advertising ahead of time. You should come up with a plan for your launch; including your launch activities and the tasks required to execute your launch. You may also want to start some prelaunch activities to get the attention of early customers.  Launch activities should not be limited to marketing and PR.  They should include all of the bits and pieces needed to get your business up and running as well (e.g. starting insurance, etc).    

    After your product and operational processes have been built, you need to make sure everything works the way that you want it to and the way it was designed to. This is what “Testing” is all about. You not only have to test “normal” scenarios but also what might happen if things go wrong. This is an important step because you don’t want your new customers to have a bad experience when using your new product! Creating and developing a proper testing process will help you to ensure that nothing gets overlooked and forgotten.

    Software Development

    In software development, building your product involves three activities: “Design”, “Build” and “Test”:

    First though, you’re going to have to find a developer. This involves deciding how they’ll fit into your team (e.g. employee, freelancer, co-founder, etc), finding the right people and getting some estimates (or negotiating a salary or equity). You may also choose to hire a UX (user experience) designer to create the screens for your app.

    The “Design” phase is about coming up with the technical and functional solution for your product. The final look and feel and layout of the screens will be determined. Solutions will also be defined for the processes and functions in your app. Some other technical things will probably also be done to prepare for your app to be built – like finding a hosting site, setting up a code repository, creating developer accounts for mobile apps, etc. 

    It’s important for you to make sure you review and approve your solution. You want to see what you app will look like and understand how it will work.  It’s easier to adjust things at the design stage rather than waiting until after your app has been built!     

    After your app has been designed, you get to the actual “Building” (finally!) Here, the developer codes your app and performs some testing on the code components. You’ll probably be required to provide the content that your app requires and if you’re building a mobile app, you may want a separate website as a marketing tool. It’s also during this phase that you’ll take your solution and determine how to test it.  

    In large corporations, the “Test” phase is broken down into different types of testing. The technology team covers “systems”, “integration” and “performance” testing, while the business team will organise “user acceptance” and “beta” testing. A summary of each type of testing is below:

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

    Unless you hire a full-service agency, it’s a good bet that you’ll end up doing all of the testing for your app – except for performance testing. Testing involves a different skillset from coding, so you’ll find that many developers won’t be able to do this properly.

    As the business owner, you’ll need to keep an eye on your development team during these activities.  You’re the “project manager” for your project which means you’re responsible for making sure your product gets delivered! Your development agency may provide a project manager – but that will only be for the technical components. You’ll still have to oversee all of the activities required to build your app – even managing your project manager!

    “Design”, “Build” and “Test” activities can occur simultaneously as your product is broken down into pieces and each piece is completed before going onto the next piece. This collaborative approach often allows you to develop product components a lot faster as team members are working on something together which reduces the amount of back-and-forth time and decisions are made more quickly. However, it does require some experience with the software development process to work this way and you’ll have to be a lot more involved in the day-to-day project activities.

    As you can imagine, there’s lots do here – not just on the technical side, but also on the business side.  It’s easy to feel overwhelmed.  Knowledge is power though – and if you know what to expect, you’re one step ahead!    

    Product Management

    You still haven’t launched yet, so there’s not much managing that you need to do. As mentioned previously, you’ll have to put together a launch plan so that you can get those early customers on board.

    …. and you’re ready for lift-off (almost!)

    So there your have it – you’ve built and tested your app. You should be comfortable with the way the app is working and you have completed all of the preparation activities for your launch.

    In the final article of this series, I’ll look at the last phases in software and product development – the implementation and launch of your app. I’ll then explore what happens next.

    [last updated: April 20, 2018]