Great Products Consulting

Tag: product definition

  • 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.
  • Get from “idea to launch” with my new checklist!

    Get from “idea to launch” with my new checklist!

    If you’ve got a great idea for an online platform or mobile app, but you’re not sure where to start – you’re not alone. Tech can be intimidating for those that have never had any experience with it before. Sometimes you want someone to guide you through the process – but you just can’t afford to hire someone to help you.

    The good news is that building an online platform or mobile app is a process.  This means there are clearly defined activities that you can follow to reach your end goal. Once you know this, the whole thing becomes more manageable – you just have to take it one step at a time.      

    Introducing the idea to launch checklist

    Today, I’m pleased to introduce the “idea to launch checklist”. This downloadable checklist contains “must-know” tasks in 15 core areas, so you can turn your good idea into a great product. It provides a plain-English roadmap for your journey. You’ll see the main activities for developing a product, and the tasks involved in each step.

    The idea to launch checklist came about as a way to take non-technical people through the creation of a digital product. Like the design and manufacturing of any product or service, platforms and apps have their own brand of jargon and their own unique complexities.  This checklist needed to be written in a way that anyone could follow.

    I understand that not everyone wants to be an expert in software development. Business owners and working professionals certainly have enough things to do and learn! This checklist has been designed with you in mind. If you’re serious about building your own digital product, then the information in this foundational checklist is definitely in the “need to know” bucket. 

    Did you know that on average only 16.2% of software projects are completed on-time, on-budget and with the features and functions originally requested?

    Having worked on technology projects for almost 20 years, I’ve learnt a lot about software development – to a point where it’s mostly routine and I don’t have to think about what to do. Throw in 8+ years in product management, and there’s all of this experience that I took for granted.

    It made me realise that this lack of knowledge is costing people money.  I’m sure people would learn a lot from their experience, but I think they would prefer not to spend so much money on those lessons!

    As someone that’s been doing this for so many years, I really want to help people avoid this situation. So, I’m sharing my experiences and knowledge with people that have had their “light-bulb” idea, and are ready to do something about it.

    Here’s a taste of what you can expect from my checklist:

    • 21 ways to evaluate your idea. Let’s be real – you need to know if you’re backing the right horse.
    • 20 critical steps to finding the perfect developer. This is not the time for speed dating.  A bad decision will cost you time and money and could even delay your product going to market.
    • Plus 25 tasks that will ensure your product testing is rigorous and effective…. If you’re really going to do this, you want to do it right.

    Think about it – you can’t ride a bike the first time you try it. In fact, before you perfected riding on two-wheels, there’s a good chance you rode a tricycle or had training wheels. You also probably fell a few times.  Maybe you could only make it to the end of the driveway before putting your foot down. Eventually though, you made it to the end of the block and around the park a few times.  

    Building digital products is much the same as this. That’s just the way life is. It often takes a few goes around the block before you’re comfortable with what needs to be done. You can try it with two-wheels for the first time without the training wheels, or you can get some help to make it easier on yourself.

    This foundational checklist is all about action. I want to see you get that platform or app built, and I want you to get there in a straight-line path. So, if you’re ready to build your platform or app, click here to find out more.

  • What’s in your platform or app? (Product Definition)

    What’s in your platform or app? (Product Definition)

    Taking your idea and making it into a product involves a very important step around defining what you want your product to do. This product definition (or product requirements) form the foundation for what happens next, so you need to take some time to understand what you need to look at.

    Previously, I showed you how to write high-level and detailed requirements. In this article, I’m going to look at how a product or service is made up of more than just the thing you use it for. Think about the last time you used a platform or app. How did you interact with it? Along with the core thing that it did for you, what else happened? This will get you thinking about what your whole product will look like.

    Let’s look at example:

    AirBnB allows people with rooms or houses to rent them to people who are looking for rooms or houses. The core things that it allows renters to do includes:

    • Searching for rooms and properties
    • Making a booking (pay and reserve accommodation)

    This is the essence of the service. There are obviously other things that you can do – like book experiences, cancel bookings, leave a review, etc. People supplying the accommodation (aka hosts) also have access to a whole bunch of other features – from listing their accommodation to managing their bookings.  All of these things are  functions in the product.

    I want you to start thinking about the other things that are needed to make your platform work.  So, let’s get started.

    1. Privacy and Data Security

    In order to make a booking on AirBnB, you need to create an account. To do that, the platform needs to collect a person’s personal information including name, address, phone number, email addresses and payment information. This information requires special handling and treatment because of privacy legislation. Privacy and data security are two very important areas to keep in mind when you’re defining your product.

    2. Legal

    When you open an account on any online platform, you might notice a checkbox that says “I agree to the Terms and Conditions”.  This little box is very important.  When someone checks that box, it creates a contract between you and that person.  This contract allows you to do things like charge the person for using the platform, and it also limits your liability if something goes wrong.  Get a lawyer to create your terms and conditions to ensure you get the best protection.

    3. User Account Management

    Once someone has created an account, they’ll probably need to update it at some point. User account management is another function that you need to think about. What information can someone change on the account? What other things will they be able to add or control in their profile?

    4. Pricing

    Your pricing model will have a big impact on the development of your platform or app. It’s pretty straight forward with AirBnB because you pay a rate per night and a cleaning fee (as determined by the host), and you also pay a service fee. However, some platforms are a bit more complicated – having different pricing based on usage, number or resources or accessible features. All of the rules for this kind of pricing have to be built into the platform.

    5. Customer Servicing

    What happens when a customer has a question about how the platform works? Or maybe they can’t login and access their booking? Customer servicing is an important part of any product – and platforms and apps are no different. Think about what methods you want to use to provide customers with a great experience – both on an everyday basis and when things go wrong. What process will be followed? What will you need access to in order to provide support to your customer?

    6. Data and Reporting

    On the business side of things, you need to think about what information you need to understand how well your platform or app is doing. Access to data and reporting are a must-have when running a tech business. Think about what metrics will be important to you, and how you want to receive that information – is it a dashboard, a report or a .CSV file, etc?

    7. Admin

    There are a lot of things that happen behind the scenes to run and operate a product. All of these admin functions need to be included in your platform or app.   May be a customer’s account needs to be updated? Or may be you need to add content on a regular basis? These tasks should also be included in your product definition.

    8. Integrations

    Integrations involve connecting your platform or app to another application. This might include email automation systems, a CRM, a payment gateway (to collect payments), an accounting system, etc. What other applications do you need to run and operate your product?

    What this means for you…

    An idea is initial view of the main thing that your platform or app will do. It describes the problem that you want to address and your high-level solution for it. However, a developer can’t build a platform or app from an idea. In order to get your product built, you need to have a better idea of all of the things that you want your platform or app do – this is your product definition.

    More importantly though, you have to remember that a product is more than just the core things that it does. There are lots of surrounding parts that are needed to run and operate the product. Remember to include these pieces as you take your idea to the next stage. They’ll help you to get an accurate quote for your project and you’ll be in a better position to run and operate your product as a business.

    Need some help defining your product for your developers?
    Check out our requirements writing course.

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

  • How do I prioritise what I want? (requirement prioritisation)

    How do I prioritise what I want? (requirement prioritisation)

    Prioritisation is probably a concept that you’re familiar with – you take a list of things and figure out which ones are more important than the other ones. Sounds simple enough?!

    When you’re building an online web platform or mobile app, prioritisation comes up all of the time! In this article, I’ll look at prioritisation as it relates to defining what you want your product to do. This notion of requirement prioritisation is a difficult one to grasp – because everything is important!  I’m going to take you through this process and share some tips for prioritising what you want.

    What are you prioritising?

    Requirements describe what you want your product to do. Requirements range from high-level statements (e.g. The user will be able to create an account) to detailed statements (e.g. The user will be able to create an account with their first name, an email address and a password). Every requirement needs a priority so you know how important it is.  

    Prioritisation methods

    There are really two main prioritisation methods:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have; and
    2. Ranking

    Let’s look at each of these in a bit more detail:

    1. Low/Medium/High or Must Have/Should Have/Nice to Have

    This is a simple categorisation of your requirements based on the following criteria:

    1. High/Must Have: These are the things that have to be there in order to launch your product. They are critical to the success of your product. If these things don’t work, you have to delay your launch until things are fixed.
    2. Medium/Should Have: These are the things that “should” be there for the launch of your product, but don’t stop the launch from going ahead if they’re not built or not working properly.
    3. Low/Nice to Have: These are the extra things that you’d like your product to do, but they’re not all that important to your product right now.

    All of your requirements are given one of these priorities. Initially, your product will be focused on the “high priority” requirements, and if there’s time and money, the “medium priority” requirements can be included. Generally, your “low priority” requirements will be built after your initial launch.  

    2. Ranking

    Ranking is a straight-forward list that starts from 1 (the most important) and increases sequentially from there. It dictates the importance of one requirement relative to all other requirements. This is the method used in the Agile methodology to manage the list of things to be built. You start with 1, and keep going down the list until you reach your last requirement. You’ll have to decide which of the requirements on your list need to be included in your initial launch, and then you’ll continually develop your product after that.  As new requirements are discovered, these need to be slotted into the list based on their priority.

    How do you decide the priority?

    So, how do you decide if something is a “must have”? Which requirement is #1?

    There are several things to consider. Requirements are important if it’s:

    1. Critical to solving the main problem/need/goal you’re trying to address
    2. A legal, regulatory, or security requirement
    3. Needed for a satisfactory user experience
    4. Inclusion will help you to achieve your goals
    5. Driven by potential customer and user feedback

    The key is to be as objective as possible in setting your priorities. You may even have to test how important a requirement is by talking to potential customers and users. Prioritisation should be an informed business decision. Make sure you take the emotion out of it. You can’t make everything a “must have” – otherwise, you’ll never launch!

    Why is prioritisation important?

    You’ve prioritised all of your requirements, so how does this help you build your platform or app?

    Prioritisation comes into play when you’re deciding how much you want to build. Unless you’ve got all of the time and money in the world, you need to make decisions about what to include in your development project. If you’ve prioritised your requirements objectively, you start with your highest priority requirements first. Most people are constrained by their budgets, so prioritisation forces you to decide if you really need something or not.    

    Prioritisation also becomes a consistent and easy way to make decisions about your development project, and to communicate the importance of each requirement to your team. If a high-priority feature is taking longer than it should to build, or if there are issues with it during testing, then everyone knows what they should be working on.

    Prioritisation is ongoing

    After you’ve launched, you continue to add new features and functions to your product, and you’re going to have to decide what to build next. You should continue to prioritise these requirements, so that you can make objective decisions about the improvements you make to your platform or app. This will ensure that you’re spending your money on the right things – and that’s critical for your product’s success.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What's scope creep?
     
  • Customers vs users (what’s the difference and why do I care?)

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

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

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

    Customers

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

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

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

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

    Users

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

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

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

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

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

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

    Why do you need to know this?

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

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

     

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

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

  • 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.