How Formstack Product Managers, Designers and Developers Work Together

Although our process for building Formstack is certainly customized for our team, the over all concept is worth sharing.

The key for us has been making cross functional roles work together throughout the entire process. We now have product managers, designers and developers working from start to finish on features in cross functional teams. Let me walk you through each high level step and some key points that take place in each step.

1. Discover and Define the Problem

Owner: Product Manager

We have an amazing group of product managers that make sure we are solving real customer problems and not building features from the idea fairy. Product Manager as well as UX Researchers go out and talk to existing customers and potential customers that fit our target personas. Pairing details found in these calls with data from Mixpanel gives our team a huge advantage in solving our customers problems.

2. Design Sprint Planning

Owner: Product Designer Manager

Design Sprint Planning: We start a three week sprint, one sprint ahead of the development sprint. The first thing we do is have a sprint planning meeting where we review the top priority projects. Each designer will commit to what they think they can deliver by the end of the sprint.

3. Kickoff Session

Owner: Product Designer

This could be the most important step of the whole process in my opinion. Everyone that will work on the project is at this meeting. This includes developers, designers, product managers, UX researchers and sometimes a third party project owner. We also use this kickoff session template to make sure we document and cover everything we need to cover.

The first part of the session is to make sure everyone understands the problem. It’s the Product Manager’s job to make sure everyone understands the problem that is to be solved. To ensure the team is on the same page we write the user stories as a group.

The second part of the session is for brainstorming around the problem set. The group will agree on which user stories to focus on for wireframe sketching.

• Each person (yes even the developers) then breaks off for 20 minutes of sketching with pencil and paper.
• Once the 20 minutes are up we’ll present our sketches. It’s best to have everyone take photos of their sketches and upload them to the shared document. You’ll see a lot of consistencies as everyone presents. You’ll also likely see some interesting outliers. It’s important to not critique these sketches. This is a brainstorm sessions after all.
• Pull it all together. Group consistencies and identify those interesting outliers you’d like to explore. Discuss scope and possible issues.
• Last thing we do is identify measurable goals or metrics we’d like to track that would show this feature is a success.

4. Design Sprint

Owner: Product Designer

After the Kickoff Session the product designer has a very clear picture of how to proceed. The user stories are clear and well understood. With everyone’s impute the designer is also aware of any technical limitations.

With all this information the designer will create low fidelity mockups. Once the mockups are ready they’ll schedule and conduct customer calls to test usability of the feature. These calls often expose some great insights that result in some key iterations and improvements.

Ultimately our final design solution is documented for development via Pivotal Tracker and Invision App.

5. Development Sprint

Owner: Developers

Our development team uses a strict agile process and works on 3 week sprints. We chose to do 3 weeks sprints because we wanted 2 solid weeks of development time and a week for QA, planning and retrospectives.

Sprints are started with sprint planning meetings. During those meetings the product manager will review the top priority projects. We’ll then go through each project and assign points to user stories via planning poker.

Then, development happens! Like every other step this is still a very collaborative process. The designers are still involved but mostly in a support role helping out where issues come up. The main collaboration is between our developers.

QA is also included in this part of the process. Every bit of code goes through our QA testing process and must be approved before we launch the feature.

6. Launch and Retrospective

Most features go through a Partial Roll-Out phase to limit support issues and allow for easier iteration “in public”. Once a feature is stable and has proven it’s solving the customers problem we’ll go to a full rollout.

The day after feature launches, partial or full, we get the whole team together for a retrospective to talk about what went well and what could have been better.

Challenges

This flow is very collaborative. This makes the the whole process and specifically the first week of sprints planning heavy with lots of meetings. This is certainly something we are still working through but it’s also great to see us planning things out.

Teams have to self manage themselves and what they commit to taking on each sprint. We’ve found this to be a little challenging for our teams and they’re over committing themselves.

There are lots of other small challenges, but those challenges are not unique to our process.

Conclusion

You’ll see a repeating theme through every step, collaboration. Including everyone on the team from the start saves a lot of time in the long run. It’s much easier to catch issues early rather than right before development is about to start.