UpTech's playbook for building great products.
There’s a lot that goes into building great products. This is a playbook of activities we think any company should do, whether you engage us to help do the work, hire us to consult on how to do it, or do it yourself.
- Although there’s a logical ordering to some activities, we take an agile and flexible approach to product development. This playbook is a way to organize the activities that need to happen, rather than a linear sequence of phases.
- Although lengths are shown for some activities, these are rough estimates that differ depending on the size of the problem you’re trying to solve and what’s uncovered along the way.
- This is a work in progress – it’s not comprehensive and it’s not perfect. We started it as a tool for ourselves (and our clients) to help scope projects and frame our conversations, and we’re happy to share with anyone who finds value in it.
Stakeholder Interviews & Workshop
This step is focused on developing a common understanding of who you’re making your product for and why. Together, we’ll identify and develop hypotheses about:
- Personas. Who do we think the primary and secondary personas are, are they the same as your customers, and what are their goals?
- Product. What’s the long-term vision for the product? What’s the elevator pitch? What are the key differentiators? What needs to be built first?
- Business. What’s the business model for the product? How does this product fit into the overall company strategy?.
|Typical Length||1-3 Days|
|Logistics||Members from UpTech and the stakeholders from your team in 1:1 and/or group meetings|
|Deliverables||Provisional personas; working product vision statement/charter; research plan|
You’ve got an idea. We research the competitive landscape, focusing on features, strengths/weaknesses, missed opportunities, etc. While tracking your competitors and benchmarking your product against theirs should be an ongoing activity, a few days deep dive at the start of a project is good to help understand the goals relative to what’s happening in the market at large.
|Typical Length||1 week|
|Deliverables||Competitive research presentation|
Meeting, listening to, and observing real users (or potential users) is how to validate and refine hypotheses about your users and your product. For most consumer products, 5-8 interviews is usually about right. For business products, 3-5 interviews per role is a good rule of thumb, with a mix of:
- people in different roles within the same company
- people in the same roles within the same company
- people in the same roles at different companies
If there is a clear primary persona, extensive research with secondary personas (system admin, for example) is not necessary — 1-2 interviews may be enough.
|Typical Length||About 1 week per 10 interviews (including time to reflect, synthesize, and review the results)|
|Logistics||Research should ideally be in person, one-on-one, and on location in the context where people would use your product.|
|Deliverables||Personas; research summary; updated product vision statement|
We can evaluate your current or future technology stack, code quality, automated test coverage, CD/CI tools, etc.
|Typical Length||1 day - 1 week|
|Deliverables||Technical assessment and recommendations|
Customer Journey Mapping
Feature lists don’t tell the story of your product. Mapping the overall customer journey gives you a sense of how your product fits into the daily life of your users, identifies opportunities for innovation, highlights critical paths through your product, and begins to create a picture of how features interact with each other and will get used.
|Typical Length||1–2 weeks|
|Logistics||Combination of working sessions with you and studio time|
|Deliverables||1 or more illustrated customer journeys|
If user stories are bite-sized features and functionality, epics are the larger themes that are the starting point for creating those user stories, can be used to help organize your product roadmap, and to make rough estimates of level of effort.
|Typical Length||1 week|
|Deliverables||Epics; rough level-of-effort estimates|
Well crafted user stories articulate the features that make up your product vision in a way that focuses on the measurable value to deliver, rather than a specific design or implementation approach. They are a starting point for design (how should it work?), test-driven development (did we build it right?), and how you will measure success (did we do the right thing?).
|Typical Length||1-2 weeks; ongoing during agile development to refine, add, and remove stories as needed|
|Deliverables||User stories; acceptance criteria; measurement criteria|
Wireframes & Flow Diagrams
Wireframes and flow diagrams help illustrate how the features and functionality described in user stories will be arranged into a coherent user interface that people can use and understand. User stories are often refined, added, and removed in the process of creating wireframes and flow diagrams. While it’s important to get the “gestalt” of the interface worked out before front-end development begins, this work can and should continue throughout the agile development process.
|Typical Length||1-3 weeks to start; ongoing during development|
|Deliverables||Wireframes; flow diagrams; revised user stories|
Before you commit to writing code, prototyping gives you sense of how the features you’ve talked about hang together. Changing your mind in prototypes is much quicker and easier than changing code. Prototypes can be built early, with wireframes/rough designs, or at a very high fidelity to test smaller interactions.
|Typical Length||1 week+|
|Deliverables||Click-through prototype(s) that can be used for internal review/feedback and for user feedback sessions|
Visual Style Creation
Your users aren’t going to use wireframes and you want your product to look great. Rather than focus on creating complete visual comps of every screen, element, and interaction up front, we focus on establishing a visual style early, then working out and refining the details during the agile development process.
|Typical Length||1 week+|
|Deliverables||Visual style guide; graphic assets|
Because we prefer to work as an agile team, we don’t typically do a separate step of detailed design to draw up full comps and write complete specs. Instead, this is usually ad hoc. But, if we’re not doing the dev work, or are working with a remote team, we can spec everything out.
|Typical Length||Integrated with development or to be scoped|
|Deliverables||Detailed design specs; graphic assets|
User Feedback Sessions
Putting your ideas in front of users to is a powerful tool for gathering directional feedback about whether you’re building the right stuff as well as specific feedback about how to refine features and functionality. Conducting sessions once is good, but conducting studies on a routine basis (every 6-8 weeks) is an excellent way to stay grounded with qualitative feedback about your product.
|Typical Length||1 week per set of sessions|
|Logistics||Requires recruiting, screening, and scheduling participants; a location for conducting and viewing live sessions|
|Deliverables||Live session viewing; session recordings; summary report of findings and recommendations|
The agile process isn’t just about writing code, but is where the rubber meets the road of proving the hypotheses you’ve made and refined before you start building. It includes iteration and refinement of user stories, design, automated tests, front-end code, back-end code, creating and/or integrating supporting services, and more.
|Deliverables||Delivery of your product; although we generally take a continuous delivery approach to development, in practice it’s usually on a weekly or bi-weekly cadence|
Process & Platform
Project Planning & Management
In order to organize the development work, track progress and changes, we create a product roadmap, set up a ticketing system, enter, organize, and sequence epics, user stories, and other tasks, schedule routine meetings, etc.
|Typical Length||1 week setup; ongoing management as part of agile development|
|Deliverables||Roadmap; ticketing system setup with initial set of epics/stories/tasks; scheduled meetings; guidelines for how to run the development process|
Putting the systems, tools, and criteria in place to measure the success of your product are just as important as building the features themselves. Then you need to pay attention to those metrics and assess what they mean.
|Typical Length||1 week setup; ongoing as features are released|
|Deliverables||Setup of tools and systems; ongoing reporting on success metrics|
While there are frequent development releases of your product during agile development, you may want to coordinate public releases with marketing, sales, training, press, etc. to ensure that as you deliver your product over time, it tells a coherent story about the product vision and roadmap.
|Deliverables||Public delivery of your product|
Get in Touch
If you have comments, questions, or are interested in how to put this into practice, we'd love to hear from you!