How to execute a successful product strategy — Part 2
Part 2: Design & Development
In the second article in our series How To Execute A Successful Product Strategy, we’ll continue with Product Discovery and talk about what happens after completing feature prioritization and defining a deliverable scope.
This post won’t talk about choosing the right technology, platform, and libraries, or scratch the surface of hybrid vs. native or web vs. mobile. We’ll focus solely on the critical processes and essential elements you need to get the most out of your design & development cycles.
In today’s digital world, the last product standing is the winner; it’s survived the longest by continually improving, iterating, and optimizing by incorporating user feedback and data analysis. There’s no silver bullet to getting to the top; it’s a multi-year grind with countless iterations. Think of every user test and interview as opportunities to discover new market openings and validate product assumptions. When it comes to the design and development cycles, we stay lean and agile. We iterate and test everything continuously — even after launching v1.
How we use estimations, guesswork, and other fortune-telling techniques to define the budget
In Product Discovery, we figure out a ballpark estimate for our efforts, but now it’s time to be precise. Ever since the dawn of software development, developer estimates are known to be off. Really off. So, what have we learned?
Most importantly, dedicate enough time to produce accurate estimates. Any developer or designer you assign to come up with these estimates will need a lot of context around the project, and plenty of time for onboarding. Ideally, this individual would already have taken part in Discovery.
Should the person in charge of the estimates be the same person who’ll develop or design the project? It helps, and we always prioritize the seniority and experience of the person working on the estimates. We need to give them plenty of time to go through each requirement and, when they’re done, have a sanity check with their peers, like code reviews with developers. This process does take time. For example, developers need to analyze dependencies, research libraries, SDKs, and APIs, all while considering the architecture and experience required to build each component.
During our design and development processes, we estimate twice. We make the first estimate before we start, and we use it to staff the design team correctly and get a good sense — say 80% — of the effort needed for development. But, as we iterate in the design phase and test different concepts, we find that the final development effort may vary. After completing the design phase, we make a final development estimate, scale the team accurately, and plan the timeline accordingly.
Have super detailed checklists for designers and developers
Here are two examples of the detail level we go into when we are creating our proposal for the client. Every proposal needs to check every single item on these lists.
We use these checklists to catch typical early omissions in our estimations so we can be as precise as possible. Just make sure you tick all the boxes!
Be rigorous with project planning and tracking progress
Once we start a project, how do we track its progress? We need to offer visibility to all stakeholders and avoid the kinds of terrifying situations when we’re at the 80% mark on the timeline and only 50% done!
Our core system for tracking progress is Jira. Here we can monitor everything: all the tasks, hours spent on each task, estimates vs. actuals on tasks, and even move tasks accordingly depending on what stage they’re in — from development to quality assurance and back.
But, more importantly, how do we plan projects? We use Jira Advanced Roadmaps, a plugin that enables creating Plans for forecasting milestones and release dates.
We use Plans to manage team availability, plan each team member’s capacity in a given period to account for vacations and time off, and even plan the amount of productive work done during the day (which might be different for juniors and seniors). In return, Jira produces a realistic schedule that updates as we progress. We often provide access to Plans for our clients, so they have real-time insight on the project’s progress.
To get started, break down your project into individual tasks. We usually do this in detail during the estimation process, and now we add it to Jira Plans. We follow the adage that no task should take longer than two days, to ensure our estimates are correct. If it does, break it down into smaller chunks of work. After this, we assign the team and plan the tasks for each person.
During the process, we’re capturing dependencies between the tasks, from design to development, and by connecting as many tasks as possible through dependencies, we get a realistic timeline. This also enables the project manager to better understand where the opportunities are for shrinking the timeline, and where to expect the potential blockers.
By assigning tasks to developers and designers, we can easily see our sprint capacity planning. In the following screenshot, you can see the green bars representing workload in each sprint for each team member. In our example, the bottom two lines are designers whose work is done by the 7th sprint, but more importantly, the third developer has some free capacity in sprints 3 and 4 (3rd and 4th green bar in the 3rd row). This is a crucial indicator to project managers to show if the sprint was planned correctly and if team members are under-booked or over-booked.
By combining Jira and Plans, we avoid learning about delays during the final mile of a project, and we can act immediately if we see we’re off track. If we realize after a few weeks that our 3-month project is facing a severe delay, we’ll instantly move to either descope certain features or add another developer. You can always solve these types of problems if you catch them early.
Eat that frog!
When planning features, we tackle the biggest, hardest, and most important tasks first (“Eat that frog!”). We leave less essential features for last. This way, if something unexpected happens and we need to launch early (or more likely, we get delayed), we can push them to the next release because they’re not critical.
Choose your favorite, iOS or Android
When planning a project, it’s easy to say we want everything launched simultaneously, both the website and native iOS and Android apps. But there are certain benefits of selecting only one platform to launch on first.
- Only one development team will be blocked or delayed by technical difficulties when focusing on one platform. There can be backend or API issues, or problems with an SDK or technology that needs to be integrated into the project, or even changing requirements. When you’re developing on two platforms in parallel, like iOS and Android (or even three, if you add the web), you could have three dev teams blocked, losing time and depleting your budget.
- If we focus and release a beta version on only one platform, we’ll get super useful user feedback, which we can apply immediately to other platforms. This results in a better product on those platforms from day one, and we also minimize going back and forth and doubling (or tripling) our efforts to implement the feedback across all platforms. Use only one platform as the lab rat.
- To reiterate, after launch, it’s easier to A/B test on one platform and iterate through a few sprints to find the ideal flows and optimize features. If you intentionally delay launching on other platforms for several weeks, you can implement your findings from A/B testing on the first platform across the others immediately. This is even more true if your first platform is the web, as costs of iterating and launching are significantly lower than on mobile.
- And ultimately, it results in lower costs. The second platform will have all the dependencies resolved and a clear path through the development phase, resulting in shorter development times and saved budgets.
Alternatively, we plan projects so that the second platform is at least 1 or 2 sprints behind, as a minimum. That way, the project won’t be a victim of delayed dependencies (e.g., non-functioning backend, missing design assets, etc.). One caveat about this approach is that it doesn’t allow testing or immediately applying feedback and changes.
Validate your designs
An essential step in our design and development process is design validation and testing. We make sure we’re designing (and later, building) the right product that solves the right problem.
There are two mandatory user test moments: at the end of the UX phase and at the end of the UI phase. Regardless, conduct numerous tests throughout the design process and focus on usability testing. We need to avoid designing detailed UX and UI before we validate key user flows.
User testing after the UX and UI phases
How do we find users to test our designs? We need the actual target users of our product. If we’re working with a client, the client might provide contacts of their existing customers or help us segment the right user profiles. We can also find users online through Craigslist or social media.
How do we perform these tests? Mostly through online conference calls. We used to rent dedicated user testing facilities equipped with cameras and one-way mirrors, but we’ve found that recording online meetings is often easier (and COVID-19 compatible!). These days, we use Google Meet and Zoom, and we ask our users to share their screens.
Minimum sample size for user testing
We have to find the right balance between the effort required and the quality of the information received. We believe the minimum number of users for testing the designs after the UX and UI phases is 10. You might have heard about an ideal sample of 5 users giving most of the information you need at this point. Still, we’ve found that testing the designs of $1MM+ projects with only 5 users might leave key decisions to 1 extra vote, and so few users provide only a subset of expected feedback.
We’ll build a clickable prototype and send the user an Invision link. We have the user talk while progressing through the prototype. We prepare a script, and after the session, we watch the recording and write detailed notes.
Another option is usertesting.com, which offers an unmoderated test. We give the users a live prototype and a script to follow. The benefit is the scale: we can get same-day results and perform testing on a much larger number of users. But because it’s unmoderated, meaning we can’t jump in, provide clarifications, or ask additional questions, we don’t get the same insights as we do with live user testing.
Daily user testing during the design phases
It would be wrong to wait several weeks and reach the end of the UX or UI phase to perform initial tests and get feedback. We can perform quick user tests every few days in our office. While the office might not be the perfect target group, we still gain enormous insights into a product, and this kind of testing helps validate certain decisions. We conduct in-office tests with a minimum of 3 people.
We perform testing on actual devices. Seeing beautiful designs on the screen is one thing, but once the user has the screen in their hands, it is easier to identify real problems. Watch your users with the product, and have them talk as much as possible. It’s also helpful to record these sessions either by video or audio to review their feedback later.
Iterating is the easiest in the design phase because you can make changes almost instantly. Whether it’s a small scale office test or a large scale with target customers, plan for user testing in two steps. First, prepare the actual user test (including preparation of clickable prototypes, scripts, and include time for reviewing the sessions afterward). Next, dedicate a certain amount of time to fix the designs based on user feedback. This way, when you do your second round of user testing, you’ll be on the right track.
User testing takes time, but if you don’t do it properly, you take significantly higher risks and face more expensive development changes, or even worse, you launch a flawed product.
Good chemistry between designers and developers is the key to agility
Design and development are not separate phases. The developers should be part of the design process, and the designers should be part of the development process. There is no clearly defined line between them. We need to avoid having developers see designs for the first time after the designs are finished. If you wait that long, it’s already too late to change anything.
How can the developers take part in the design phase? First of all, developers know their platforms inside out and can provide constructive feedback on utilizing platform specifics optimally. The designer’s goal is to create the best possible user experience and amaze the audience; the developer steps in to make sure everything is doable within the planned time frame, meaning budgets.
At this stage, we also need to be careful not to take creativity away from the designers. But it’s also important that developers be given the opportunity to provide feedback throughout the design phase and ask questions about a specific case the designer might have forgotten to cover (e.g., what happens to a particular button when scaling the app with screen sizes).
Creative chaos meets precision development
There are huge benefits of having all the product disciplines under one roof like we do at FIVE. You get to unleash the designers’ full creativity with developers’ detailed precision and have them work closely throughout the project. This allows for ultimate agility and a seamless product process, so make sure you’ve done everything you can to keep both groups part of one team.
At FIVE, we aim to account for developers’ time in the design phase, and vice versa. We also invest a lot in mutual education. For example, the designers organize workshops on how to use Figma, and the developers are always recommending the best design talks from WWDC.
How can designers take part in the development process? The designers should review every bigger milestone in the development and provide feedback. They validate that the designs were correctly implemented, and there are no rough edges or cut corners. The designers should also be available throughout development to provide developers with additional or missing assets, review their work, and ensure that the developers have as little to interpret as possible.
One key component in any successful collaboration between designers and developers is your choice of the design tool. Figma is our designers’ weapon of choice. And it also has great features when it comes to collaboration with developers and specifying design components.
Figma supports naming styles, similarly as developers would in CSS. It adds a level of abstraction to ensure proper usage in both design and development. For example, a color named $error-warning ensures no one makes the mistake of picking a wrong hex color while designing or developing.
Figma also has built-in visualizations to display redlines for measurements and distances between elements. Developers can select an element and hover over other elements to measure the distance between them. It simplifies and even removes the need for the specification documents, as everyone can go directly into the design and check the margins, paddings, and relations between different objects.
Development ready
And finally, we clearly mark finished designs “Ready for development.” This helps developers find their way amongst dozens of pages and screens and focus on what they’re interested in most.
When the design is finally complete and signed off on by all stakeholders, successfully passed through detailed user testing with rave reviews, and the lead developers have provided feedback throughout the design phase, it’s ready to be handed over to development. The handover is usually an extended meeting with the full development team present, and designers present the design system they’ve created.
Stay one step ahead, be ready to handle the (un)expected
The biggest stress in the design and development phases is handling unexpected changes. No matter how detailed you were in the design phase, there might be completely new information available during development. For example, maybe a client hasn’t resolved licensing issues and needs a feature to be removed; the backend has significantly changed; the development team hasn’t anticipated all the complexities and is blocked. It happens everywhere, and it happens on nearly every project. So how do we handle the expected?
The role of the project manager
A key-person for managing the expected is the project manager. Apart from managing and driving the project forward, their role is to resolve dependencies between teams, anticipate which tasks might not be ready for implementation yet, and reorganize work to ensure maximum productivity. They are also in charge of constantly communicating the scope and timelines to the whole team to avoid ambiguity and misunderstandings.
When something unexpected occurs that adds to the workload, how do we update our plans? Here are several strategies:
- We can descope a less important feature to ensure we keep the same deadline
- We can move the deadline (and add a change request to the project that extends the deadline)
- We can grow our capacity either by working overtime or adding people to the team
Each strategy has its pros and cons. Sometimes there aren’t any “less important” features that we can move to the next release. Other times we’re constrained by fixed deadlines (e.g., conferences or broader company initiatives). Sometimes, when we’re close to the release, it doesn’t make sense to add more people to the team because too much time would be spent on onboarding to make an addition genuinely efficient. It’s up to the project manager to balance all the strategies. More importantly, it’s up to the project manager to plan ahead, anticipate potential roadblocks, and eliminate them ahead of time.
Daily standups significantly help with project planning, and we find them an essential component of any process on an operational level. They ensure a free flow of information, and the project manager needs to make sure the standups are productive and that everyone is heard. We limit standups to 15 minutes, and if more discussion is required, we break out into separate groups. Standups aren’t only for developers — we have daily standups in the design phase as well. Overall, they help keep everyone informed and facilitate sharing information that might not otherwise be shared.
The role of the dev lead
In the development process, the second in command is the dev lead. While the project manager manages the timelines and work, the dev lead is responsible for doing things the right way and ensuring that all developers’ work across different teams fits well together.
The dev lead’s first task is building the product’s architecture, and when doing so, they need to assume all the ways the product could change and be changed. Here’s a recent example: We were tasked with creating an app that would run solely on Android tablets. At a particular moment in the middle of the project, the decision was made that the app needed to support Android-run remote controls with a screen resolution of 320×240. That’s a huge change, but luckily, thanks to proper planning and our use of Clean Architecture, we ended up reusing everything, save for rewriting the UI. Read more on our blog about how we implement Clean Architecture on Android.
The next critical responsibility of the dev lead is setting up code reviews. On a smaller project, each pull request gets reviewed by the dev lead, and on larger projects, we’ll have features leads in charge of specific product components. There’s no magic here, just hard work. We adapt our code review strategy depending on the team size, project size, and the number of seniors on the project.
Constant code quality across projects
The main purpose of code reviews is to ensure constant, high-level quality across the codebase, enabling any developer to take on any part of the code. It’s a mantra we set years ago: you shouldn’t be able to recognize who developed which feature. All code should be written adhering to the coding standards of your organization. So when project planning, devote enough time for code reviews to make sure your senior developers aren’t bottlenecked by taking several days to do code reviews later. The process does take a bit of time, but it should always be streamlined, seamless, and never blocked by other tasks.
And finally, the dev lead sets up the continuous integration and delivery process. This ensures that each pull request is building correctly, and we always schedule nightly builds that run integration and UI tests. We plan writing tests as part of our tasks, for example, if something touches on sensitive business logic. That way, by integrating writing tests into our daily routine, we immediately have a comprehensive build and integration system ready. Setting up a build system enables easy distribution of builds with a click of a button to clients and stakeholders, to designers for their reviews, and for the QA team.
Get ready to launch
So, when does the quality assurance team come into play? Don’t wait until the final two weeks before product launch to release the power of the QA team on your (at this moment) unstable product. We provide builds to the QA team as soon as certain features, user stories, or flows are developed. We have QA team members participate in the design handover because they’ll start creating their test scenarios then.
As part of the pre-release process, we need to implement particular SDKs to provide more insight into our products’ performance, and the most important ones are obviously for analytics. We’ve seen so many projects with analytics SDKs built-in but without careful planning on strategizing events, funnels, or demographics. Analytics tracking should be closely connected to business goals (OKRs) defined in the Product Discovery phase. On mobile, we also implement Firebase Crashlytics to make sure we’re aware of all crashes so that we can respond instantly.
With mobile apps, once the product is ready for the public, we need to start planning its release in the respective app stores. Actually, that’s wrong; we should have started planning the release at least a month before the scheduled launch. This takes time, as we’ll need to prepare the assets for the App Store page, screenshots, videos, and icons. We also need to get the App Store accounts ready — this step tends to fall victim to bureaucracy, causing subsequent delays.
For the actual release, we can employ different strategies. We can release the app in private alpha — similar to user testing — but just with the real app build. Private alpha has only certain features implemented to test and validate key flows. We can do a private beta release, which also targets a smaller group of users, but most of the app features are done and ready. And we can do a public beta release, where we open the app to the public to receive feedback that we can later take into account and implement in the final product release.
And once we’re ready, we hit the launch button! We then take a well-deserved break and celebrate for a moment, but soon enough, we’re back in the saddle iterating on design and development, analyzing Firebase Crashlytics and analytics, and planning future releases.
Feature flagging
We often use a strategy called feature flagging: these features that are continually being deployed but not necessarily released into production. This means that for every new feature we’re working on, there might be several others that we’re working on in parallel. These are all part of the same codebase but hidden. Once a feature is done and thoroughly tested, we enable it in the codebase (flag it as ready; that’s where the name comes from), and it shows up to the users! It’s much easier to develop this way on a single codebase than to develop each feature in a separate branch, and then, once it’s done, merge it into the codebase and start performing QA tests. Doing this introduces a lot of unexpected issues and more work.
Do it all over again
The first release is probably going to be a much bigger effort. At FIVE, that varies between 3, 6 up to 12 months from the idea to the first release, depending on the project. But after that, you should repeat this cycle over and over again at a much faster pace. You can also run design, development, analytics in parallel, but how to run a proper agile/scrum process is material for a whole new blog post, and we’ll leave it for next time.
Thanks for reading Part 2 of our three-part series on How To Execute A Successful Product Strategy. If you’ve missed it, here’s part 1, and part 3 is coming soon!
Originally published at https://five.agency on November 9, 2020.
