Business and Customer
We start by getting to know a client, their business, and their customers. What is the problem they are trying to solve? How does software fit in? Why aren’t existing solutions getting the job done? What are customers’ expectations? Why build something now?
Part of getting to know a client, their business, and their customers is learning about their domain. What does your current business process look like? What are the pain points in your current process? What do you like about your current process? What external entities influence your process? Who carries out the process? Who are the output stakeholders?
All of this information, and more, not only helps us better empathize with your needs, but also suggest changes to scope that will increase ROI.
We next ask a client what they want from their product. What are its capabilities, its jobs, its functions? What job is the user hiring the product do to? How does the proposed solution solve the user’s problems and meet business needs? If necessary we may run a design sprint.
We then prioritize requested features into Needs, Wants, Desires. This informs our next few steps of UX Design, Engineering Spike, and Defining Scope.
A UX designer is involved early to get a deep understanding of the businesses needs and objectives. After assessing the client’s goals, the designer will facilitate exercises including customer interviews, see | do mapping, and other activities that help tackle the biggest issues at hand.
Many teams have found it valuable to run experiments prior to engineering a new product — most notably design sprints popularized by Google Ventures.
The purpose of an engineering spike is to determine how to design a software system to support a client’s stated needs and priorities. It takes as input business goals, product concept, platform, non-functional needs such as security, scalability, and monitoring. We evaluate specific designs, technologies, data models, etc in order to frame out how we would build a software system and mitigate risk. If necessary we will consider additional factors such as the client’s existing tech stack, 3rd party APIs, and tooling.
With inspiration from The Four Big Risks, when defining project scope we consider:
- What is viable for the business, expressed by the client
- What is usable by users of the product, expressed by the designer
- What is feasible to build, expressed by engineering
- What is sensible to ship, recommended by product manager and team given the project’s assumptions, constraints, risks, dependencies, and team capabilities
We plan releases as a large chunk of the desired product that has immediate user value. This helps us understand how to break up the project into parts so we can prioritize, estimate, and start building.
We scope and sequence releases based on:
- Release goal
- Relative value and complexity of each release
- Reducing unknowns as fast as possible
- Obtaining user feedback as early as possible
- Minimizing waste
After release planning, the outputs are:
- Project scoped with high level estimates for all releases
- First release planned and estimated with granular user stories
- Areas of highest uncertainty/risk marked for follow up
Plan Product Launch
The purpose of planning product launch is thinking through all activities involved with operationalizing the product in order to set up the client for success after our engagement ends. This includes transferring ownership of the product, systems, codebase, licenses, etc to the client as well as training client teams on specific technologies. This step helps clients transition from new product development to go-to-market and operating a production system.
In order to work together effectively we need to agree on some simple agreements between the client, Very, and any additional collaborators. With respect to planning, some examples: Who will play what role, how do we handle feedback, definition of ready vs. definition of done. We also agree on practical things like quiet hours, preferred meetings times, and so on.
Following iteration zero we start our first iteration of incrementally building a new shippable product. We have found this helps us all row in the same direction and manage risk effectively.