Path to Discovery

Author: Rachel
December 20, 2019 | 5 mins to read

Whether you're developing a new product to complement an existing ecosystem of products or an early-stage entrepreneur ready to take your idea to the next step, before the product can be developed, it must be translated into technical requirements. This is a bit more complicated than 'Build a Login System'. That single statement can be interpreted a number of different ways, resulting in a handful of solutions that still meet that requirement. This is why a second (or third...) step is typically taken to further refine what is needed - Will the user login with a phone? Using a phone number? A username? A social media login?

As you can see, there's a lot of uncertainty over what the 'Build a Login System' requirement should be. By using this framework, you'll further refine these basic requirements to enable the design and development of a solution that is flexible enough to meet your business needs with room to grow. It'll help you transform your idea into something more tangible, enabling you to see different opportunities for developing your solution.

Why is this needed?

This framework defines a process to develop a clear set of deliverables that you desire so an accurate quote can be provided. It will be most useful for businesses and entrepreneurs working on their first technical product and still getting familiar with the process involved in working with a developer or development team.

In general, web and software development can take a lot of time. As a result, request for quotes and proposals can come with a range of figures. These numbers often come from the submitter's interpreted understanding of the requirements and either use a bare minimum figure, a "good quality" figure, or a "best quality" figure. In order to provide a reliable and accurate quote, we (I speak for all developers and development agencies) need to understand what you want to build.

If you work with an agency, they often have project managers/business analysts that work directly with you to translate these requirements as the project progresses. Depending on your budget and business process, this may be your preference.

A Bit About Development

It's important to understand from a high level why development can be so simple and complex at the same time. Development teams may start with a single person and grow to a large number of specialized skillsets. Developers in a team of one must be fullstack developers. Usually, when teams are under 5 developers, there is less room for specialization, and you'll find that most developers are typically fullstack developers. This is most common in startups and small agencies. As companies grow, developers end up specializing based on the needs of the product and the interests of the developers.

What is a fullstack developer?

Fullstack developers handle the data modeling, data persistance, the service layer, designing the user interface, and deployment. They are the jack-of-all-trades that do everything to develop a new product. Most still have a preferred specialty.

What other specializations exist?

I won't go into great depth - I just think it's good to understand a bit more about the developer landscape, especially if you're thinking about bringing your development in-house down the road.

  • Front-end developer: These developers handle the user interface and sometimes the user experience. They focus on making sure things load fast and efficiently on the end-user platform.
  • Back-end developer: These developers handle the data modeling and service layer, getting the data from the database to the front-end in a format that is easy to use.
  • UX Developer/Designer: These developers and designers are responsible for ensuring the product is intuitive to use. They interview users to understand how users think and design wireframes and mockups to illustrate this workflow.
  • DevOps Developer: These developers are responsible for the deployment of applications. They deal with automating application builds and server configurations. Sometimes these roles are further specialized with cloud infrastructure specialities, where developers are Cloud Architects and able to set up the necessary infrastructure to automantically handle heavy traffic loads and deploy new versions when a new release is ready.
  • Data Scientist: Data Scientist model, transform, load, and crunch data to identify unique patterns that answer questions useful for customers and business units alike.
  • Product Management and Business Analysts: These roles help bring everything together, working with customers and internal stakeholders alike, to enable development across specializations that improve the business as a whole.

Development teams in support of a product evolve to fill in gaps as the product evolves. Data heavy solutions may build out the Data Science team first. The right combination often depends on the skills of the existing team - there is no one-size-fits-all.

Framework Background & Development

For the last few years, I've spent a lot of time working with startups and learning more about a typical startup's journey. After attending MIT's selective New Ventures Leadership program, which introduced the 24-steps of Disciplined Entrepreneurship, I began working on a framework to help startups prototype new products. Along the way, I attended more workshops on design thinking, ideation, business modeling, and much more. Through all this, I've simplified and extracted the most important elements to develop a framework that can be used for identifying key technical requirements for prototyping and developing minimum viable products. This framework incorporates elements from MIT's Disciplined Entrepreneurship Curriculum developed by Professor Bill Aulet and related frameworks to provide a concise approach to translate business requirements into technical requirements. With these requirements, it'll be possible for developers like myself to quickly understand the problem you're addressing and help you develop a solution.

Assumptions & Pre-requisites

This framework has some pre-requisites and assumptions:

  • Market research has already been conducted to understand the potential customer base and market need
  • Key functional requirements have been identified

The Framework

The framework is broken down into 3 sections: Solution & Background, The Product, and User Personas and User Workflows.

Solution and Background

This section covers highlights from your market research. It provides the background we need to understand what value your product provides to users, so that we can help you adequately highlight those features.

The Product

This section provides a high-level overview of the product. It identifies how the product should be built and the top features needed for launch.

User Personas and User Workflows

This section takes the above step a bit further by refining the requirements for each feature set. It allows you to build user personas to understand the different user groups and how these user groups might access your solution differently.

To work on an online version of this framework, take a look at my Discovery Framework.

If you want to download these worksheets instead and work offline, you can download a copy here.

If you have any questions, schedule a free 30 min. consultation, and I can help you get started.

Photo by Juan Rumimpunu on Unsplash