Great Products Consulting

Tag: validation

  • Common mistakes when determining whether you will make money

    Common mistakes when determining whether you will make money

    In my last article, I talked about how to figure out if you’ll make money from your online platform or app. This article looks at some common mistakes that people make when they’re assessing their idea.

    Given that the simple equation for making money is that revenue (number of sales x price) is greater than your cost, then there are three main areas where people get it wrong:

    1. Overestimating demand
    2. Setting the wrong price
    3. Underestimating cost

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

    1. Overestimating demand

    When looking at your financials, it’s easy to overestimate the number of people you think will buy your product. Even if you account for the time it takes to ramp up the number of users you’ll get, if you start with the wrong number, you’ll be behind from the beginning.

    In product management, we’ve got a lifecycle diagram that illustrates sales over the life of a product. Guess what it looks like at the beginning…

    That’s right. At the beginning of most new products, sales are tiny compared to later on in their lives.

    2. Setting the wrong price

    Pricing is such a complex thing. There are many ways to charge people for your products and services. Pricing models vary to include options like monthly subscriptions, tiered pricing, or freemium – but what’s the right one? And then there’s the price itself. If the numbers are too low, you may not cover your costs. Too high and no one buys from you. That’s the challenge of pricing.

    When you’re thinking about whether your platform or app will make money, you may pick a price that is too high or too low. Couple this with a demand estimate that is too high, and you won’t be able to pay the bills!

    3. Underestimating costs

    This is a big one when it comes to platforms and apps. First, your development costs are probably going to be higher than you think. Second, you’ve probably underestimated the ongoing costs.

    Unlike most physical goods, software platforms and apps have ongoing operating and running costs. You have to pay for hosting, someone to monitor your platform, fix problems, and if you’ve got a mobile app, you’re going to be updating it every time there’s a new Apple or Android operating system update. Then, there’s the user expectation that you’re constantly improving your platform and rolling out new features. All of this costs money – cash to be exact, as that’s usually what your vendor prefers.

    What can you do?

    The main problem here is that forecasting and financial planning is not an exact science. If it were, everyone would be making money.

    The challenge, then, is to reduce the risk of you being wrong. Along the lines of lean methodologies, you want to research and test all of your numbers. By testing the assumptions that you’ve made about your numbers, you can increase your chances of making money. It’s a critical part of product development. Making a guess – even a fairly educated one is not enough.  Do yourself a favour – spend the time to figure it out.

    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.
  • Will your platform or app make money?

    Will your platform or app make money?

    The idea of building a platform or app and having this steady stream of passive income is very attractive prospect. Unfortunately, the question of how to make money from an app is not so clear cut.

    There are a lot of factors that affect success, but often the issue is that the numbers weren’t right in the first place. It seems obvious, but it happens in business – all of the time.

    In the simplest of terms (and sometimes that’s all it takes), your financial equation is going to look at two key components – revenue and costs. In order to operate and hopefully make any money, revenue (or cash in) has to exceed costs (or cash out). I’ve put it this way, because there are many startups that don’t make money until they sell their business (and when that happens, they can make a lot of money).  However, in the meantime, they still need cash to pay the bills on an ongoing basis.

    A simple way to gauge your financial success

    Success is a relative term and a very personal one, so your definition will depends on the goals you have of a platform or app. If you want to replace your income, then that’s a different measure than supplementing your income. It will also affect your approach to building your product.

    So, a very simple gauge as to whether you can make money is:

    1. Decide how much you want to make a year.
    2. Decide how much you can charge for your platform, and an average revenue amount per customer (e.g. what’s your price?)
    3. Divide how much you want to make by your average revenue per customer.

    This gives you the number of customers you need a year to reach your target. Does this number sound reasonable? If not, you’ll need to play around with the numbers to see if you can get the required price and number of customers to more manageable amounts.  It may not be possible. In this case, your idea won’t make you the money that you’re looking for.

    Now you have to think about the costs.

    If you think you can make enough money from your platform or app, the next part of the equation is your costs.  This will include the initial development costs, but you’ll also need to include the ongoing costs of managing and enhancing your product. On top of that, you have the overheads of running a business – insurance, marketing, advertising, legal, accounting, payment providers, banking, etc. It can all add up and eat into your hard earned revenue.

    The next step is to take your revenue every year and deduct the costs. If the number isn’t positive, then you won’t make money that year. As simple as that.

    You’ll then have to go back and either adjust your revenue numbers to cover all of these costs, or you’ll need to cut back on your costs, so that you can still make money.

    But when will you start making money?

    The thing about the above revenue number is that it’s your ideal number. The reality is that you’ll need to ramp up to that number – and it will take longer than you think. This means that you won’t be making all of that money on Day 1.  The important part of this means you need to have enough money to cover your ongoing costs. Don’t spend all of your money on the upfront development!

    An important cashflow indicator is called a ‘payback period’. This is how long it takes to pay back your original investment. Only then do you really start making money (after taking out your ongoing costs). Most software development projects in corporate land look for a payback period of about 18 months to 2 years. As a small business relying on your own money, this will probably be longer, as you may not have access to the same resources you need to scale quickly.

    What next?

    The above is a very simple view of figuring out if you can make money, but it will give you a quick indication of whether the numbers can stack up. For a more detailed view, talk to an accountant or financial advisor where you can get advice on a model to suit your specific business.

    The bottom line is that it’s not so easy to make money as you might think. Even the big startups don’t actually make money yet, and their worth is based on their valuation as a business. However, if you’re a small business owner looking to enhance your income in the short to medium term, you do have to have a good handle on the numbers before you start.  Otherwise, you’ll find yourself running out of money before you can figure out if your platform or app can be successful.

    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.
  • Does your platform or app solve a problem?

    Does your platform or app solve a problem?

    Ultimately, a product or service exists to solve a problem, or it addresses a need or goal of the customer or user. Without that fundamental piece, a platform or app is doomed to failure. Understanding this is an important part of validating your idea.  This article looks at what to consider, and why it’s important to understand the problem your solving when you want to build a product.

    So, what’s the problem, need or goal?

    At the end of the day, you don’t want to spend your time and effort building something that isn’t helpful to people in some way. Whether it’s around productivity or maybe just entertainment, your platform or app has to have some purpose for people to use it.

    Generally, we talk about solving problems with products. That’s because people are driven to look for products or solutions because they’re having trouble with something. Some problems are more trivial (“I’m bored, let’s find a game to play” or “I’m hungry”) and some things aren’t (“How do I do my taxes?” or “What insurance should I buy?”). Bottom line – if there’s no problem, you’ll find it very difficult to get people to use your platform or app.

    It’s not always doom and gloom, and that’s why I like talking about needs and goals too. To me, needs and goals are a variation of a problem, but with a positive intention – if you’re looking to meet a need (“I want to learn a new skill”) or if you want to achieve a goal (“I want to book a holiday in Perth”), then you’re equally motivated to find a solution.

    Regardless, in order for it to be successful, your platform or app needs to do something useful for someone.

    Is that problem painful enough for people to seek a solution?

    Your platform or app is the solution to a person’s problem, need or goal. By using your product, your clients and customers will achieve the outcome that they’re looking for. But how painful is the problem? Is it a little itch or a full-body rash?!

    If you think about the buying process, there are generally a few steps that people go through before pulling out their wallets and purses. This means that you want to make sure that the problem you’re solving is painful enough for people to go looking for a solution. If I have a hole in my sock, do I look for a hole-fixing service or do I just buy new socks?  Conversely, if you’re talking about needs and goals, then you’re thinking about how important this is to someone.

    If you’re product is free or low cost, then it’s less of an issue as it’s low-risk for an individual to try your service or download your app. People will use it as an option for evaluating different alternatives. The challenge then falls into my next point.

    Are there enough people with the problem? And how often do people have this problem?

    I’ve combined these two questions together because they speak to how many people you need to use your platform or app. You’ve found people with problems, and they’re painful enough to look for a solution. But are there enough of them?

    Unless you’ve got a high-ticket price, volume is key to any platform or app. There are a lot of overheads to cover with a platform or app. You’re looking at 10-20% of your initial development costs to keep your systems running every year. This means there needs to be enough people with the problem to use your product, so you can pay your bills. This is a really important point. Be realistic about the number of people that you can get to sign up to your platform or app when doing your financial analysis.  This is usually where a business falls over.

    Another element of the volume equation is how often will people use your product. Problems are not all equal in importance. Some problems can be solved as a one-off (e.g. buying a present) and some happen over and over again (e.g. ordering takeaway). You can solve a problem in a minute, while others take years. If you have a subscription or membership product, then you want problems that take a while to solve. For smaller problems, you want people to keep coming back every time they encounter the problem. While it’s important to have a large number of users for your platform or app, you also need them to use it again and again.

    Why should I care?

    If you don’t first understand the problem, need or goal, then it’s no point building a solution. No one will use it. “That would be cool” is generally not a good reason for building a platform or app.

    I’d also encourage you to explore the problem. This involves thinking about how painful it is. You want to understand why people might have the problem, and what motivates them to want to solve it. If the problem you’ve identified isn’t a big deal for them, then you’ll have a tough time convincing them that you have a solution for them. This research will also help you to build a better product by making sure you address the pain.

    Finally, think about how many people this problem affects. How many of them you could realistically get to use your platform or app, and how often can you get them to use it. This is critical to the long-term success of your product. Your product may be great at what it does, but without volume and consistent use, you’ll struggle to keep it going.

    At the end of the day, products are created to solve problems, so take some time to think about the one that you want to address in order to have a successful platform or app.

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

  • What is a Wireframe?

    What is a Wireframe?

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

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

    Wireframes in Product and Software Development

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

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

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

    Types of Wireframes

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

    1. Low-fidelity wireframes

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

    2. Medium-fidelity wireframes

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

    3. High-fidelity wireframes

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

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

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

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

    Why should you care?

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

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

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • Idea validation isn’t much fun, but you should still do it

    Idea validation isn’t much fun, but you should still do it

    As you may know, I’m a big advocate of idea validation – the activities around deciding whether you should pursue your idea. In a previous article, I talked about why it was important, and some ways that you can get an initial view of whether your idea is a good one.

    With alarming stats on small business and new product failures, it still surprises me the number of people that don’t take idea validation to heart.

    Actually, maybe it doesn’t.

    Idea validation sucks

    Market research, competitor research, talking to potential customers and users – it’s hard work… and not very sexy. In fact, it’s not much fun at all. You sit at your desk, checking competitor website after competitor website, doing keyword research or begging people to reply to your survey. Then you might dig through mounds and mounds of industry reports to get some statistics to back up your business idea. You might even put some inflated numbers on a spreadsheet to see if you can make any money. If you’re truly ambitious, you’ll try to test your idea – whack up a landing page and try to get people to sign up for your future product. Or maybe you go out and actually talk to some potential customers or users.    

    Let’s face it – many of you probably wouldn’t consider doing most of this. Most of you would rather go straight to building your platform or app, and turning your idea into a reality. That’s the sexy bit.

    There are lots of reasons why people start businesses or build products, but if your goals in any way involve making money or they rely on lots of users, then idea validation is a critical step.

    Let’s put it into perspective

    Popped some acetaminophen or ibuprofen lately? Imagine pharmaceutical companies didn’t validate their ideas for new drugs; they didn’t spend years tweaking formulas, and researching their behaviours and interactions with the body. What if they just made a pill and starting selling it?

    “But Karen”, you might say, “that’s different – I just want to build an app.”

    Ok then, let’s look at something closer to home.

    Founded by Eric Reis, “lean startup” is a product development approach that some of you might have heard of. Did you know that lean startup borrows from scientific method to build new products?

    The theory is that traditional business plans don’t work for products that have a high-degree of uncertainty. Opening a new restaurant or starting a new skin care business both have fairly well-known business models that allow people to follow a standard path of product development. When the outcome of the product is not as sure, then Reis argues that experimentation is the approach required to confirm (or refute) the assumptions that you’re making about your idea. Therefore, you have to test every single part of your business plan (e.g. the problem your idea solves, the solution you propose for it, your target customers, the benefits the product provides, costs, revenue, etc). Until you do that, you shouldn’t spend a lot of money developing your product. This process of testing could take 6 to 12 months to complete. You have to run experiment after experiment – using control and variable groups to prove (or disprove) a hypothesis.

    Imagine idea validation on that scale?! Generally, this kind of validation requires a team of people and a heft monetary investment. However, the potential rewards are in the millions of dollars.

    So, where’s the middle ground?

    My view is to do the least amount of work possible to either prove or disprove that an idea is good one.  If you’re not sure, then dig a little deeper. Start with getting online, and doing searches on potential competitors and getting statistics on market size. You can get a lot of information online these days, which makes it a good place to start. You’ll soon find out pretty quickly whether an idea is feasible or not.  

    Don’t forget to run the numbers.  Platforms and apps have overheads and require ongoing updates.  Make sure you have the money – not just to build one – but also to keep it going.  On the revenue side, think about your pricing and how many users you need to cover your costs – and hopefully make some money.  If you can’t make it work on paper with sensible numbers, then it’s going to be even harder to do it real life!

    At the end of the day though, there’s no substitute for talking to people that you don’t know – especially those that will be your users. So, start with a survey to get a feel for the interest. Follow it up with a few 1-on-1 interviews. You’ll learn so much from them about what they’re really looking for.     

    Finally, if you want to really get serious about validation, look for ways to test your idea with real people.  Can you get people to pay money for something that doesn’t exist yet?!

    Validation doesn’t guarantee success, but it can prevent you from making a mistake

    Ultimately, there are no guarantees for success – which is maybe why people skip validation in the first place. The instinct to just “have a go”, is a strong one, and we don’t get anywhere by doing nothing. If money weren’t involved, I would probably agree. The experience of “doing” is so valuable and so powerful. However, if I have to spend 6 to 12 months, and $50K or more to build a product, then I want to be sure that I’m getting at least $50K of learning out of it! Otherwise, you’ll just have a hole in your pocket. At the end of the day, that’s what idea validation is all about. Will you get something out of developing your idea that is worth the investment? If not, then maybe it’s not such a good idea after all.        

    Want to get serious about validating your idea? Check out our Idea Validation course

    Yes! I want to learn how to validate my idea
  • 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.

  • Intro to Product and Software Development and Product Management (part 2 – at the beginning)

    Intro to Product and Software Development and Product Management (part 2 – at the beginning)

    In my last post, I introduced you to the concepts of product management, product development and software development. In this post, I want to bring it all together and explain what it means to a non-technical person starting on their app development journey. This all might seem a little daunting, so for now, here’s what you need to know:

    Product Development

    “Ideation” and “Analyse” are the most important parts of product development. In these phases, you need to be able to come up with an idea and see if it’s worth building:

    There are lots of different ways to come up with ideas for an app – but most usually come from personal experience – either at work or outside of work. Look for problems in your day-to-day life that might need solving.  Maybe it’s something in your industry or something in your job role.  Maybe it’s something at home, while travelling, parenting – the possibilities are endless!  

    After you have an idea, you want to make sure it’s the right one to pursue.  What makes you the right person to build this app?  Where might you need help? How big is the market? What’s the competitions like? There are lots of ways to evaluate your idea.  If you don’t validate your idea, then the rest of the process is really irrelevant. Validating an idea is about making sure you don’t want to waste your time and money on building an app that doesn’t allow you to achieve your goals.

    The product development process has natural “gates” that give you permission to stop what you’re doing and to go onto the next idea. If you don’t think your idea is good enough, keep repeating the “Ideation” phase until you have an idea that is more desirable. In the “Analyse” phase, if the idea doesn’t pass your validation criteria, you go back to the “Ideation” phase.

    Click Here
    To learn more about idea validation

    If you’ve decided to go ahead with developing your idea, you’ll then need to “Define” your product. This is about writing down what you want your product to do. This is an important process because it dictates how your product will end up!  Spend some time here really understanding the processes that people will go through, what you want them to do, what they’ll want to do and what information needs to be captured and stored. Also, consider all of the processes that might be involved in running your app – for example, how will people contact you if there is an issue? How will you respond to them? etc.

    Software Development

    The “Requirements” phase of software development overlaps with the “Define” phase of product development, so your defined product also forms the basis for the Requirements phase. The Requirements phase in software development will focus on the actual app being built; whereas the Define phase will look at everything that’s need to deliver and run the product.

    This phase is about telling people about what you want build – which makes it pretty important! If you can’t articulate what your product should do, then you might end up with something that is vastly different from what you expect. You’ll then spend a lot of time and money trying to make it right.

    Developers use the information that you provide about your product to estimate the cost of building it. This means that you want to be very clear about what you want your app to do. A lot of projects end up costing more money and take more time to complete because new things come up later in the project.

    Product Management

    Your product hasn’t been built yet, so the elements of managing the product through its lifecycle don’t come into play yet. However, you’ll want to start thinking about who your first users will be as you enter the next stages of building your product.

    What happens next?

    After you’ve figured out what your product needs to do, it’s time for you to start building. In our next article, we’ll look at getting your app designed and built.