Product creation frameworks are a dime a dozen. There’s the Lean Startup from Eric Ries, Google Ventures Design Sprint, and the IDEO process just to name a few. You might have noticed many terms and acronyms being thrown around as well, like minimum viable product (MVP) and simple lovable and complete (SLC). It’s a jungle out there but we’re here to help you through the creation of your product and options for how to look to develop it.
You may be wondering what’s the best product creation framework? As with a lot of things, there isn’t a perfect fit for every person and product however, we have observed that many of the product creation frameworks do follow a similar pattern:
This is not unlike the 13 step process that we walk through together in the Founder Community! Funnily enough, the three we’ve chosen to cover all are depicted with circular graphics. Let’s check out these styles in a little more detail.
Design firm IDEO came up with the IDEO design process. Their process is focused on human centered design whether it is being used for physical or digital products. Human centered design is an approach to problem-solving that starts with people and ends with solutions that perfectly suit their needs. 6 phases make up the circular process:
This stage is about observing the target audience, absorbing what you see, and being open to creative possibilities. Your goal is to better understand who you’re designing for. Take note of their pain points and try to put yourself in their shoes to experience what they’re experiencing.
This stage is where you take what you learned during observation and brainstorm how you’re going to address it. Come up with as many ideas as you can and try your best to keep your target audience’s interests in the forefront of your mind.
This stage is pretty self-explanatory, you focus on building a prototype of your idea quickly. You don’t need to get dredged down in the fancy details right now, your goal for this phase is to get a working prototype in the hands of an end-user.
This step is about gathering the feedback given by your prototype users. This is the most important phase of the human centered design process as you need the input to know you’re on the right track or how to shift and make improvements.
This phase is where you take your feedback and make changes to your design. Keep repeating the process of iterating and getting feedback until your solution is as ready as can be. It may take multiple iterations, but you’ll learn something new each time.
This phase is where your design is ready to roll and be put out into the world. If you’re building software or a website, you continue this process again and again with each new update and improvement.
GV took business strategy, behavior science, innovation, and more into account while developing this process. The GV sprint takes place over 5 days and compresses the amount of time spent on design cycles in other frameworks. These sprints can be done when stakes are high, when there’s not enough time, or when you’re stuck in a rut. Sprints in general terms are short periods of time dedicated to getting a set amount of work done. Similar to the IDEO design process, the focus is put on getting prototypes made and gathering how they are received by their intended audience. Let’s check out how GV recommends you spend your sprint week!
Before a sprint begins, some groundwork is laid out. Here is the checklist of a few things GV recommends to be prepared:
Choose a big challenge – outline the main goal you’d like to achieve during the length of the sprint.
Get a decider – this person makes decisions stick
Recruit your sprint team – GV recommends 7 or less people with differing skills.
Schedule time with other experts – If needed, schedule some time to meet with outside experts that may not be a part of your regular team.
Pick a facilitator – This person manages time, conversations, and the overall sprint process throughout the week.
Block your time – Reserve time with your team to work on the sprint goals.
Have a space to host sprint meetings – If possible, have a set space to meet with your team in-person.
Discussions on Monday create the path for the rest of the week. Topics to cover include setting a long-term goal, map out the steps to achieve your big challenge (or a piece of it) during the sprint, and ask outside experts for extra insight if necessary.
Tuesday is for focusing on solutions. Dedicate time to revisiting existing ideas to remix and improve, sketching out solutions, and recruiting customers for Friday’s prototype test.
By Wednesday there will be a bundle of sketched out solutions to review. Time will be spent critiquing them each, choosing the best option, and finally outlining a step-by-step plan to build your prototype.
Thursday is dedicated to creating the prototype based on the plan made on Wednesday. A realistic facade is all you need to test with customers. Part of the day will be spent preparing for Friday’s tests by confirming the schedule, reviewing the prototype, and writing an interview script.
By Friday the goal has been met for the sprint and a prototype has been produced by the team. On this day interviews will take place with test users. The team will learn from their feedback and how they react to the week’s work. Notes taken will show if improvements have to be made or if the team can move onto the next idea’s prototype.
This final process was developed by Eric Ries to get a desired product in front of the customer faster. It’s all about avoiding chaos and testing your idea continuously. This methodology emphasizes speed, not unlike the GV Design Sprint we discussed prior. Let’s take a look at what Eric puts into his Build-Measure-Learn loop:
This step revolves around building the future product. They focus on building an MVP prototype, not spending huge amounts of time and resources on costly market research and extensive planning.
The team then moves onto gathering feedback from potential customers. This data can be used to find problem areas that can be focused on for improvement. The parameters for the data set prior to launch will generate insights in the next phase.
The final phase is where the team’s assumptions about the product get compared to the actual data from the last phase. They will decide to either continue pursuing the development as is or start from scratch. The option of starting from scratch is called pivoting.
Before jumping into building your product with a development partner, you have to decide what type of application you’ll be building. Did you know that there are different types of applications? Mobile applications are the ones you run locally on a smartphone and web applications are software that runs on a web server. Mobile apps are often faster performing than web apps, but they will need updates downloaded. They need an internet connection to work, but they can perform similar functions as a mobile application and don’t need updates installed locally. You’ve likely used both of these types, but do you need to decide if you’d like your app to be on one or both. If you’re thinking about a mobile application, you also have to ask yourself what operating system(s) would you like it to be available on? Operating systems are what a phone runs on, like iOS or Android. The type of application can affect the cost and time to build as well as what development partners you can work with, so having that nailed down before searching for a partner is necessary.
Want to learn more about the entire mobile app development process? Check out our mobile app development guide here.
A big decision that is inevitable for software entrepreneurs is choosing how they want their product to be built because not everyone has the skills to build it on their own! This is where choosing a development partner comes into play. There are agencies as well as independent freelancers on-shore and offshore who will build and develop your app idea from the ground up. Let’s take a closer look at your options as well as what you should be bringing to the table while having initial discussions.
There are common differences between choosing onshore and offshore partners. Offshore development means that a development partner is located in another country. In contrast, onshore development is located in the same country as you. Typically, offshore development is the lowest cost you will find when it comes to building your software. However, you are also taking on a great deal of risk with the lack of transparency and communication that is often better when dealing with an onshore development partner. On the other hand, onshore dev will typically end up costing you more.
Another choice to be made other than onshore or offshore as a source of development is to decide the type of partner. Freelance development is where a single skilled person works on your project. Their prices will vary based on their spread of skills and the time put into a project. The risk associated with freelance developers is the rate at which work can be completed. They rely wholly on their own knowledge and the time they have available to complete jobs.
While established companies can have multiple individuals, or an entire team, working on your application, a freelance developer has only him/herself as a resource.
A technical co-founder developer is someone that has the technical skills needed to build your solution and is interested in becoming invested in your product. They are similar to a freelancer since they are a singular skilled person, but instead of getting paid wages, they are interested in equity in your business. They have the same risk of the rate of work being completed, but at the same time you aren’t paying invoices and you have another person to bounce ideas off of. A technical co-founder becomes your true-blue business partner!
Development agencies have an entire team of skilled individuals at their disposal to build your product. With more hands on deck, these companies are able to have faster turnaround times, but it does come at a higher cost than other development partner types. The actual prices will vary from agency to agency. An entire team of individuals work collaboratively to work on the elements of your project. Development agencies employ individuals with different skills, so you may have the opportunity to get additional services that wouldn’t be available with a freelance or technical co-founder.
When you are shopping around and getting quotes from development partners, it’s a good idea to ask some questions about how they work. A great inquiry is to see what style of development they use for their projects. Agile and waterfall are two popular styles that you may run into. In agile development the developers continually prioritize the product backlog of tasks as needed when any new challenges arise. There is flexibility in this style of development but also no hard end deadline. In Waterfall development the entire project is set with specific deadlines. There is little evolving as the project progresses but that also means there is less chance of getting off the timeline or budget.
Learn more about agile and waterfall styles as well as how long it takes to develop a mobile app in our other article here.
It would also be a good idea to ask how the potential development partner handles change requests and additions of new features. Startups almost always have some sort of adjustment, addition, or shift needed along the way during development. Growth and change happens, so what will your dev partner do when it comes time?
The most important question to get answered by each and every one of these potential development partners is probably the most obvious: how much is the quote they gave you to complete your project and what is their timeline to start and finish? A thing to keep in mind is that just because you find someone offering a cheap estimate doesn’t always mean you’ll be getting the best end product. Choosing the most expensive estimate doesn’t always mean you’ll be getting the best end product either, it mainly comes down to choosing who has the skills you’re looking for, who has the team size you’re wanting to work with, who is working in your preferred development style and development framework, and what their timeline is for the project.
A framework is a platform that gives developers a foundation on which to build software. Think of it as a template that can be customized to fit the client’s specific needs with unique code built by the developers. There are loads of frameworks and each has different upsides and downsides for different types of development projects. Your potential development partners will share what they work in and suggest the best option for your project.
If you’d like to learn more about frameworks check out our article Frameworks for Mobile App Development––5 Things Startup Founders Should Know.
You’ve chosen the partner that’s going to take your idea and turn it into the real deal, but what happens now? We suggest revisiting the wireframes and feature backlog you’ve put together (Found in steps 8 and 9 in the Founder Community) if you haven’t already done so with your dev partner. They will love how prepared you are if you bring this to your discovery phase! Most agencies will propose beginning work with a discovery phase. It is an extremely beneficial step that helps you lay the groundwork down with your new team member(s). This step does cost time and money. Agencies like us at Codelation feel it’s integral, like drawing up a blueprint for a house. The discovery phase work often includes feature backlog prioritization, finalization of wireframes, and developing a roadmap or timeline for development.
For more information on what to expect during a discovery phase, check out our blog How Long Does It Take To Develop An App?
Don’t be afraid to ask your new team member(s) questions about anything during the discovery phase. Questions about cost and scope of features should be asked now before your partner begins the actual development work. If you feel something is coming up too expensive in their estimates, discuss why it’s costing what it does and if there are options to make it simpler while still solving the problem. Sometimes features that look pretty in a wireframe are actually technically more taxing to build. They may be able to offer you a unique solution that is cheaper, opening you up to spending the saved money towards a different feature.