1.1. Prepare
1.1.1 Objective
This phase will point you in the right direction by framing the problem you are trying to solve. Sometimes the objective will be pre-defined by a tender (or proposal). Other times we may find a problem (or a market need) that we aim to solve with a new product.
1.1.2 What you will be doing
1.1.3 Steps and tools you can use
a. Review functional requirements *🥇
This is a critical step to understand what is expected of the product you are about to build, to learn about expectations, and determine the deliverables and milestones of your contract. It is also a good opportunity to start understanding the budget, time constraints and key dates for all product development processes.
Get access to all relevant documentation available so far, including the RFP if relevant (the ‘request for proposal’ document that the donor created to outline the specifications for the project), Catalpa’s proposal, the contract we have with the client, and any additional information from previous conversations including meeting notes and emails threads.
Ask the growth and partnership team to provide you with as much information as possible on all conversations and negotiations that have happened to date.
Consult with the head of sector(s) to help you better understand the challenge.Here is an example of a review we did for additional functional requirements for Estrada.
You may find that you don’t know enough in the early stages of a program to create something this detailed, even so, it is helpful to create some brief documentation outlining what you do know, and the expectations for delivery.
b. Frame the design challenge *🥇
This is critical to define what your product will try to solve. The framing exercise will get you off on the right foot and determine how you think about your solution. It is also a critical time to start bringing others to the conversation.
IDEO – a design and consulting form that has some pioneer work in design thinking and HCD to design products and services - recommends the following steps when framing your design challenge:
Start by taking a first stab at writing your design challenge. It should be short and easy to remember
Answer to ‘What is the problem you’re trying to solve?”
From your previous answer, take a stab at framing it as a design question - ‘How might we… (solve the problem)?’
Properly framed design challenges drive future steps towards achieving the desired impact, allow for a variety of solutions to be considered and tested, and take into account constraints and context. Try to answer the following questions:
What is the ultimate impact you’re trying to have?
What are some possible solutions to your problem? From an early stage / pre-discovery perspective
What are some of the context and constraints that you’re facing?
Another common pitfall when scoping a design challenge is going either too narrow or too broad. A narrowly scoped challenge won’t offer enough room to explore creative solutions. And a broadly scoped challenge won’t give you any idea where to start.
Now that you’ve run your challenge through these filters, do it again. It may seem repetitive, but the right question is key to arriving at a good solution. A quick test we often run on a design challenge is to see if we can come up with five possible solutions in just a few minutes. If so, you’re likely on the right track.
Here is a template to use when framing the design challenge. And here you can find IDEO’s method in action - see heading ‘Framing your design challenge
c. Research *🥇
You should start by doing some research. Depending on how well the contract has framed the work and how much time you have until your first product deliverable, you may be able to do a more in-depth research or a quicker one to understand the state of the art in the field you will be working on.
Internal research - Catchup with your colleagues, starting with the head of the sector that you are working with (e.g. education, program), the Head of Products and the Head of Engineering. Learn more about what other products were developed in the same field, for the same client, and for similar contexts. Ask your colleagues to provide you access to those products and any documentation that may be available (GitHub repositories, User documentation, video demos, presentations, final reports, a link to the product itself etc). Talk to product and team leads that are/were involved in the product development and learn more about their challenges, issues and lessons learned. Heads will help you identify the right people to talk to.
Online / external research - Go online, go to a library, talk with others. The idea at this point is to understand the state of products in your field. Identify patterns (features, design principles, where they are struggling).
Gather what you learned - from the internal and online/external research - in a document. This is helpful for you and the team you’re about to build.
d. Build a product team *🥇
Consider what are the roles and skills you will need to develop the product and what can be funded within your budget. Usually a product development team at Catalpa includes a product lead, engineering team (engineering lead, frontend engineer, backend engineer, full-stack engineer, etc.), design team (UI/UX designer, visual designer), product quality assurance (QA) team. Sometimes you may also need to bring in some other skills in fields such as content creators, communications, or sector specialists.
Work with your Team Lead and/or Program Manager and Catalpa’s Finance Manager to understand what resources and budget you have available.
If building a team means hiring new staff, have a chat with the Team Lead and/or Program Manager to start the process as soon as possible. Don’t forget that you will need to understand what experience and skills are needed in order to prepare the terms of reference (TOR) for the roles and organise the recruitment process.
Prepare the team charter - a document that captures each person’s roles and responsibilities. When a product is developed within a program, coordinate with the Team Lead and/or Program Manager to ensure that the program team charter reflects the roles and responsibilities of everyone involved in the product development process.
Team charter template - in dev (and an example on how we use it for a core product dev team and for a bespoke product dev team)
Last updated
