At OfferZen, we’ve created a platform where South African companies can reach out to top devs and send them interview requests. The Product Team behind this marketplace consists of two designers, a Product Manager and three devs who work closely together. Together, they take care of our three products:
- OfferZen for developers
- OfferZen for companies
- TARA - our operational teams’ CRM tool.
Each of these products has vastly different users and use cases. Developers use the platform in a transactional manner whenever they are actively looking for a job, companies use it on a weekly basis, and internally we use TARA heavily every single day.
For the first couple of months after starting OfferZen, building was quite straightforward. We knew what basic features and processes needed to be put in place to make the hiring process run smoothly. It was not a simple task, but we had confidence that we were spending our time and energy on the right things.
This served us quite well until we had tackled all the “obvious” features. Knowing what to build became much harder because we no longer had a clear roadmap. Suddenly, we were not building our product proactively but reactively - fixing problems as they popped up.
That’s why we started developing a process that allows us to make smarter product decisions. In the following post, we want to share how we decide what to build, plan the build and design the product. This should give you a good overview of how we do things at OfferZen, BUT, keep in mind: Our process is by no means perfect, is constantly being improved and sometimes changes depending on the task.
Planning
Deciding on a Goal
Every 3 months, we revisit our goals as a company and set new ones. We have an in-depth discussion with all the individual teams and print a poster for the office that keeps our eyes on the prize - you will literally bump into this in every room.
Currently, the Product Team’s goal is: Own the “full loop” of the hiring experience. That means, we are trying to really understand the interactions between devs and companies during the hiring process, and then facilitate wherever possible.
Overarching goals like the full loop ownership serve as a team specific North Star. Everyone knows what area of the product we’re working on and the kind of problems we’re trying to solve.
Creating a Roadmap
All our long term planning happens on a product roadmap that is divided into 4 sections:
- Backlog - A list of all the features that we’re planning to build in the next 3 months.
- Prioritised - These are the features we’ll work on next.
- Current - Features that we’re currently busy with - this will be a maximum of two.
- Just shipped - Features that are live and whose performance we observe.
Discovery Process
In order to create this 3-month roadmap, we start a process of discovery where we try to identify and understand all the problems related to reaching our goal and get a detailed overview of what we're facing.
- We make a list of all known issues aligned with the goal and bring in ideas for improving the product.
- We go through all relevant feedback (solicited and unsolicited) we have received from users in the past few months and contact some of the users directly to get clarity.
- We pull in leaders from our operational teams. They have the most contact with users and thus insight into how the product is being used.
- We consult our data tools, Mixpanel and Looker, to understand the issues, prioritise them and determine the impact a fix would have.
Once we’ve collected sufficient data, we choose features and problems and add them to our roadmap where we link them where possible. In cases where we’re not entirely sure which feature will solve a specific problem, we instead just add the problem to the roadmap.
Let me give you an example: One of the issues we identified was that companies didn’t have a nice way of sharing a developer’s profile with the rest of their hiring team. We were pretty confident that adding “Profile Notes” would take care of this issue so we added that to the roadmap. This feature enables a company member to share their notes on a developer’s profile with their colleagues by tagging them.
Pinning the Roadmap
In addition to our digital roadmap, we also pin a card of each feature or problem to our office wall. This physical roadmap ensures that our goals are really at the top of the mind each time we walk into our office. Each card is divided into four sections: research, design, build and reviewing metrics. We use this to track the progress of each feature during stand-ups. (The “reviewing metrics” section is relevant only once a feature has been released.”)
How We Work As a Team
Each week, we split into two mission teams. Each team consists of at least one designer and one developer, and one of the operation leads. As a group, each mission team then takes ownership of one of the prioritised features on the roadmap.
We decided that we shouldn’t design or build on any chosen feature for more than a week. Instead, we prioritise the ability to react quickly to new data, our users’ needs and frequent new functionalities on the platform.
If the complexity of a feature requires more work than what is possible in a week, we create artificial milestones to help maintain our cadence. For example, we would complete part of the feature, push it to our staging server, and share the work in progress with everyone in the company on Friday.
Design Process
Our design process consists of four phases:
Throughout the design process, we actively try to solicit feedback from all the operational team leads and allow everyone in the company to give their input. For this, we have a dedicated #design Slack channel. After hauling in all the responses, the Product Manager (PM), designers, developers and the operational lead decide which changes have to be implemented.
Conceptual Design
What happens? The entire team gets together in front of a big whiteboard and starts going through all the data and feedback from users. As a general rule, we never work on a feature without having at least one week’s worth of usage data. Specifically, we are looking at the amount of users using the feature and whether they are using it the way we intended or assumed. We then talk through the problems and sketch out a few solutions on the whiteboard until we find one that we are reasonably happy with.
What comes out? The output of the conceptual design is usually a photo of the whiteboard with a few notes in a Google Doc.
Wireframes
What happens? Once we have a clear vision of how we’re going to conceptually solve the problem, we start with a rough prototype sketched in Balsamiq. This is mostly to establish the main design concepts of the feature, such as the flow and layout structure.
Balsamiq designs are always ugly - this forces the designers to really focus on functionality. The other big benefit is that the team also has to focus their feedback on the actual functionality rather than suggesting small UI tweaks. Although only one designer takes ownership of this feature, they will collaborate and share designs throughout the process.
What comes out? The finalised layout helps us to figure out the flow and functionality of the feature and serves as a blueprint for the UI design.
UI Design
What happens? Based on the wireframes, the UI designs are then done in Sketch and published in InVision, so that we can share them with everyone in the company on Slack. Using InVision is great because it not only allows them to see how a feature will look but also to add comments and suggestions on the designs.
What comes out? The output for this phase is detailed desktop and mobile UI designs which the designated developer can use to build the feature. All our developers use Sketch, and this allows them to implement the designs without the help of the designers.
Prototyping
What happens? In the final phase, we turn the UI design elements into a clickable prototype using Axure. Having something that looks visually complete allows us to test the feature with users and get their feedback. This really saves a lot of development time. Previously, we had to actually build the entire feature before we were able to test it for usability.
What comes out? The prototype helps us to get final feedback on the design and usability of the feature. We share it with everyone at OfferZen and send it to the users on the platform we had contacted earlier in the process.
The Development Process
Our development process is broken up into three phases: architectural design, building, and testing.
Architectural Design
We usually start creating the architectural design for a feature once the conceptual design has been finalised. One of the developers takes the lead and works with the PM.
Building
Once we have finalised the wireframes, we start with some of the back-end aspects of the feature. This includes setting up data models, creating services, and exposing data to the front-end. We’ll only start with the front-end once the design process is done and all feedback has been processed.
We’ve recently started using React within our Rails app for some front-end features. This helps us separate back-end and front-end concerns and means we can almost finalise the back-end code before the UI design is being done.
Depending on the size and complexity of the feature, we deploy one or two developers to work on a given feature. In addition, we always involve one designer to help with potential changes that need to be made to work around technical constraints.
Testing
Throughout the building phase, we regularly push code to our staging server. This staging server is a close approximation of our actual production server so that we can see how the feature will look and function.
Everyone at OfferZen has access to the staging server. We often use the entire OfferZen team to help test major features before we release them into production. This is also the last place to solicit feedback before features are being released.
Release
We only deploy code to production once everyone in the mission team is happy and the feature has passed all the tests. We announce new features to users both on the platform and via email.
After the release, we closely monitor the stability of the feature and how our users are using it. Mixpanel is a great tool to see how users are using your product. We monitor the stability of the feature with Bugsnag, and the performance on Skylight.
