Services
Services
At ProductStack, our goal is to help our clients design and develop high-quality software that drives business outcomes. Our Approach is how we deliver that promise.
The ProductStack Approach is founded on the best practices from Lean, Agile, and User-Centered Design and spans all the steps needed to transform your idea into a functional product. Because of its foundation in human-centered design, it is useful when developing digital products that will be used by people, either internal employees or external customers/partners.
This article describes our approach in more detail.
The goal of the Strategy and Planning phase is to develop a shared understanding between all stakeholders on project goals, constraints, and a high-level plan. This alignment ensures that the team is always focused on delivering the business outcomes that the executive sponsors desire.
Here are the activities and deliverables of this phase:
There are business reasons why your company is investing in software products—it may be looking to increase revenue, empower your customers, or improve the efficiencies of your internal teams.
Product strategy describes how your team will achieve the desired outcomes for both your company and the users.
As a first step in forming the product strategy, we conduct interviews with project stakeholders to understand the business outcomes they seek.
Then we determine which users must be served by the product to meet the stated business outcomes.
Then we build alignment within the team on the key hypotheses around the user’s problems and the team's solution ideas.
If we’re building commercial software, we'll also do a competitive analysis to understand the target market(s), the basis of competition, and how your competitors are positioned.
It's important to understand that at this stage our strategy is a bunch of hypotheses. Later in the process, the product team will validate these hypotheses to ensure that we’re building a product that solves real user problems.
At ProductStack we practice user-centered design—an approach to developing software where our team focuses on understanding the users’ goals, motivations, and frustrations. Then, we use these insights to design and develop engaging software that users love.
"Jobs-To-Be-Done" framework guides us in this step. What it states is that customers hire products and services to get specific jobs done and make progress in their lives.
“People don't want a quarter inch drill. They want a quarter inch hole.“
Therefore, as product designers, our first objective is to understand the jobs users are using our product for, and then design capabilities that help them do their jobs faster, better, and/or at a lower cost.
We facilitate story-mapping exercises to build a job map which demonstrates the steps user takes to complete a job. In addition, we try to uncover areas that frustrates the users and then identify opportunities to innovate. These findings are documented in the form of a visual backlog or a ‘story map’ - we call this the Discovery Backlog.
Remember, not every item in this backlog will (or should) be developed. The items in the backlog are the ones we want to learn more about and validate with users. If we learn that our idea is not usable, valuable, or feasible, we will not develop it.
As we go through the product life-cycle, we continuously revisit the discovery backlog and update it based on the new insights that we’ve gained. Perhaps the users gave us some new ideas? Or they may have invalidated some other ones? We groom the backlog frequently to ensure that it reflects our understanding of the users’ needs, our hypotheses, and ideas that we plan to learn more about.
The goal of building a product roadmap is to understand the high-level initiatives and key steps we will take to achieve the business outcomes.
It’s important to note that this is “top-down” planning, so we’re not expecting to be precise. Rather, our goal is to understand key milestones, major releases, and dependencies between the various initiatives.
We end up creating one of two kinds of roadmaps—one with dates and the other with phases, depending on the audience and the messages we intend to communicate.
Also, the product roadmap is a living document—it reflects our current high-level plan and we keep it updated as we progress through the product life-cycle.
Armed with a clear vision and an understanding of what the users need, we develop a technical strategy and select technologies that will help you meet the functional and non-functional requirements of the product.
Your team may already be committed to a specific architecture and technology stack, but the process of designing the software is all about making trade-offs. To ensure that your team makes the right trade-offs, it’s important to have a consensus around the business objectives that the software must support. That’s why we recommend finalizing the technical architecture only after establishing the product strategy.
When starting a new software development project, whether you’re developing new software or modernizing a legacy application, your stakeholders need critical information to determine if it will be a good investment. For example, how long will the project take? how much will it cost? and what kind of team is required?
At the beginning of the project, we may not know enough about the users and their needs to predict with any level of confidence, the time, cost, and resources that are required. So, what do we do?
First, we manage stakeholder expectations that these are high-level estimates built upon assumptions. The value of this exercise is in gaining alignment on the underlying assumptions and the process of estimation.
Next, we practice a component-based estimation technique. We assemble a team of subject matter experts, developers, product managers, and designers for estimation workshop.
In the estimation workshop, we take each item in the discovery backlog and then estimate the type and quantity of components that will be needed. Every participants get to share their perspective which builds alignment and ownership in the process.
With all of the component types identified, we then estimate the effort required for each resource type to build one component.
Then, multiplying the number of components by the effort tells us the total effort needed for each resource type. Armed with this information, we create a resource plan and estimate the costs.
Later on, when the team has found its rhythm and have an established velocity, then we move to a story-point estimation technique.
At ProductStack we use a dual-track Agile approach. The pursuit of developing products that users love can conceptually be broken down into two high-level steps:
1. Discovery (Build the "Right" Product)
This step is all about understanding the business goals and user needs, and then designing solutions to address their key challenges before committing resources to development.
2. Development (Build the "Product" Right)
Once users have validated our solution ideas, developers can proceed to develop the application based on preestablished quality standards.
The two tracks focus on different but equally important objectives. The end result is a better software product, delivered consistently.
Product discovery is all about building the right product for the end users and one that delivers the outcomes our business desires. This is possible when the product team is fanatically focused on learning about the users and their problems. We do this by developing an understanding of the users, their goals, their jobs, and how they do it today. Armed with this knowledge, we then design solutions to make it easier for the users to do their jobs.
Here are the steps in Discovery:
Discovery Sprint Planning allows us to define the goals or the outcomes we desire from the upcoming Sprint. We select the stories from the discovery backlog that we’ll work on; stories that are either high-value for the user or are high-risk for the product team.
Because learning is a fluid and iterative process, it’s hard to time-box it. Therefore, while we need to stay focused, we must stay flexible. Our first and foremost goal is to ensure that the discovery process is yielding a design that will indeed, solve the
To ensure that the development team has enough discovered stories to work on, we always try to maintain a minimum threshold of stories that are ready to be developed. This way, if the discovery process took longer, the development team is not impacted.
Great products are built on deep understanding of the users. During user research step, we use techniques like user interviews, task analysis, and discovery workshops to develop a deep understanding of the users’ goals.
These sessions can be on-site vs. remote, or moderated vs. unmoderated.
Which methods we choose depends on our objective, underlying risks, budget and time constraints.
Irrespective of the method, we capture the insights (users' current processes, tasks, pains, ideas) in form of a story map. This gives us a user-centered and a visual way to facilitate alignment across the various team members.
Armed with a deep understanding of users and their needs, we facilitate ideation sessions and come up with solution ideas.
We modify the story maps with additional stories to fill in functional gaps, remove pain, and adjust workflows to create efficiencies. This is when solution concepts begin to take shape.
But, it is well established that users struggle to define what they want or need until they see it. We use the insights we gained from user research to prototype solution ideas.
We use different levels of fidelity depending on the stage of discovery and the user story we are addressing. Initially, we may start with low-fidelity wireframes and once we have validated our understanding, we could convert into high-fidelity prototypes.
The goal of usability testing is to ensure the solution ideas we have will indeed help users achieve their goals as efficiently as possible.
We setup usability labs and observe users interacting with the prototypes to perform key activities. We're trying to identify areas of friction between the users and the software. We have learned that there is no better way to validate our design than to see real users interacting with it.
You will get plenty of feedback from the product team during the discovery process. But remember, the product team’s feedback is not a replacement for usability testing with actual users. Ultimately, the only vote that matters, is that of your users — superseding even the opinion of your executives.
While prototypes are great to validate solution concepts with the users, they are not enough to develop the software.
In this step, the team continues to enhance the validated prototypes with detailed specifications. Specifications include three additional sets of details that engineers need:
Discovery Tips:
At the end of the Product Discovery sprint, we’ve successfully identified the functionalities that the users’ need, designed solution prototypes, tested them with actual users, and defined the specifications. These stories are now added to the development backlog, which as the name suggests, is the list of stories ready to be developed.
The goal of the Product Development phase is to develop the capabilities defined in the development backlog to the desired quality.
Here are the steps in Development:
The goal of development sprint planning is to identify the stories that can be developed during the sprint.
For this, the developers need to estimate the effort for each story. But in order for the developers to do this, they first need to understand the functionalities that were discovered.
Developing this shared understanding is critical to the project’s success. That’s why we conduct story workshops where the product managers and designers walk the development team through the prototypes and specifications. We have found this to be much more effective than handing them a bunch of documentation. As a result, the engineers develop empathy for the users as well as understand the design trade-offs that were made during discovery.
This, along with the prototypes and specifications, allow the developers to break down the stories into tasks and then estimate the effort.
Modern software architecture and technologies have become increasingly complex, leading to the specialization of developer roles. While you may have a few full-stack engineers, most teams have specialized UI engineers and API engineers.
That’s why API design is the first step during the development process. In this step, the developers design the API endpoints based on the interactions between the user interface and the back-end code.
The API then becomes the “contract” between the UI and API development tracks allowing each team to work independently.
In this step, the UI development team develops the UI code (mobile, HTML, CSS, JavaScript).
The UI team uses mock APIs that return dummy data to remove dependencies on APIs which may not be ready.
During this step, the team creates unit tests for the UI code. In addition, they also test the software for compliance to coding guidelines, visual style guides, and copy standards.
This is also a logical point where we bring the end users back to do additional usability testing and provide their feedback.
In this step, the API development team develops the API layer and the underlying layers in the logical architecture. This includes the domain model, the business logic layer, the data access layer, and the database. If needed, the team also integrates the API layer with other systems.
During this step, the team also creates the unit tests for the API layer and the layers below. They also test the code for compliance to coding and architectural standards.
Often the API track lags behind the UI track, especially when you have legacy technologies that it has to integrate with. Once, both the UI and API layers are developed, they are integrated and deployed for testing.
Depending on your organizational realities, you may develop and integrate the UI and API within the same sprint, or not integrate them for many future sprints. For example, if your product integrates with legacy systems and these external teams follow the waterfall methodology, you may not be able to resolve all your dependencies in each sprint. Unless you have the authority to influence external teams, your best bet is to plan for delayed integration and associated risks.
Once the code is integrated, it’s time to test the integrated code for the following:
The QA team find and log defects, which are then fixed by the development teams. If gaps or new functionalities are identified, they are captured in the discovery or development backlogs and handled in a future sprint.
Once a user story has passed all quality checks, it is ready to be released to the users. However, based on the specific project context, the product manager may withhold the user story for a future release. The important thing is that all user stories are developed to a level of quality that is ready for production deployment.
There you have it! That’s the ProductStack Approach in a nutshell. Our approach unifies product management, user experience, and technology teams with a strong focus on the user and the business outcomes that we are trying to achieve. That’s how we deliver our commitment of building usable and engaging products that users will love.
Start a conversation to learn how we can help you strategize, plan, and start your next software project in less than 1 week.
Copyright © 2019 ProductStack. All Rights Reserved.
17228 Lancaster Hwy, Suite 201
Charlotte, NC 28277