How our early-stage startup found its process groove
tl;dr This blog is written from the perspective of a designer working for an early-stage startup. It details how we, as a team, figured out an efficient process for product development: a combination of scrum, 2-week product sprints, and consistent collaboration between design, engineering, and our customer-facing team.
Have you ever Googled “how to improve process at a startup” (or something along those lines) and you end up not finding anything that suits your small team that is scaling fast and furiously? If the answer is ‘yes’ to both questions, I think we can be friends.
Just out of curiosity… why are there always just 6 steps/tips?
I’ve spent my entire career working with startups because I love startups. They have connected me with communities of talented and passionate professionals who have challenged and aspired me to give back.
One thing I have noticed in every startup I’ve worked at is they all come to a we-need-a-better-process phase as soon as they begin scaling their business.
Being scrappy is necessary and even fun when you’re just starting out, but eventually processes need to be put in place for keeping a healthy team and business. And that’s really when the growing pains begin.
What’s process got to do with me?
So why is a UX/UI designer writing about process blog? I believe my daily job is to facilitate better communication between our users and the product. It helps a lot if I can also communicate my vision to the rest of the team and vice versa. So, it happens that we designers tend to question process a lot.
What is the most efficient way to gather product feedback from our users?
What is the most efficient way to process that feedback?
How can we more efficiently run meetings?
What is the most efficient way to communicate our users’ needs to the team?
You get the picture.
I made sure it wasn’t just me. There are more of us.
Why so many dread Process
Sorry if this sounds awfully negative already but in my experience, there’s a lot of potential for drama. And, I don’t enjoy any of it.
It can be discouraging when your company doesn’t see value in improving process. Even more tragic is when they might see the value but don’t have a good system in place to collectively figure it out.
Here are some common reasons why companies fail when it comes to improving process:
- They don’t have time to talk about process because they are busy closing deals and shipping features. Startups are all about hustling. The team is putting out a lot of fires every day; they’re trying to land new customers, hire new employees, build new features, etc. and the leadership simply doesn’t make the time for something that doesn’t appear to have immediate impact.
- They make you believe they want to involve you in process creation, but in reality they don’t want to change their old ways. At a previous company, I was given a chance to stab at improving the process. It turned out they didn’t actually want to change. All they wanted was confirmation that things were perfect as they were. While I meant well for the company, my attempt to point out potential improvements only led the leadership to see me as a threat to the current power structure.
- They have a dedicated someone constantly working on process, but the rest of the team has no idea how it will affect their work. This has to do transparency in your organization. When process making is dealt in silos, the team will experience many unpleasant surprises when it eventually rolls out.
- They know process is important, but they aren’t entirely sure how to go about fixing it. OK, now we’re talking. This is a perfect timing to start researching what other companies have done and yadi yadi yada. Make sure you look into both successful and unsuccessful processes in order to leap through some obvious trial and error.
Ok. So, now what? How do we go about it?
What process looks like at Routific
When I accepted an offer at Routific, I knew the company would help quench my thirst for running things efficiently because it is exactly what Routific does — we help delivery companies around the world operate as efficiently as possible.
There are numerous resources you can dig out from the Internet these days: lean UX process, lean startup process, cross-functioning team process, and many more. I’m especially a big fan of Spotify; they’ve done a great job sharing their team structure and process with us!
The company is made up of small clusters, called ‘squads’, which run like lean startups within the Spotify organization. They are completely autonomous, yet they are also encouraged to have structured interactions with other squads by way of tribes and larger groupings called chapters and guilds.
But this process is designed to help manage a team of thousands. How can we, as a team of 14 people, work together to find a more efficient process in everything we do?
Here’s what we did at Routific:
Step #1: Research what smart companies have already done.
Here are some of my Google keywords:
- Lean process
- Lean startup process
- Cross functional team
- Squad-based team
During my research, I discovered great references from two companies: InVision and Spotify. I also interviewed Julian Richards, previously a Senior Strategy Manager at Telus Digital, now Director, UX for SAP Enterprise. I tapped into some webinars like Jeff Gothelf’s Lean UX.
Step #2: Come up with a big picture for our own sprint cycle
During a brainstorm session, we asked ourselves: what do we want to achieve during the sprint? What are the outputs of the sprint? Ask these questions with team leads (consider them as your focus group). This sets a good start for structuring a foundation of the process.
Step #3: Create in-depth processes for sprint
After some trial and error, we’ve finally decided to apply the scrum framework. Scrum is an agile process made for a team that work on complex product development: Your team breaks down a complex problem into smaller pieces and collectively works on them.
And, we run 2-week sprints; for each sprint, we have a sprint-planning session where we assign and estimate tasks together as a team, and a sprint-review session where we see how we did. And most importantly, we can’t forget about rewarding ourselves after each sprint so we have been naming all our sprints after confectionaries: tiramisu, blueberry pie, gateau de metz… you get the picture. If we meet all our sprint goals, we celebrate during the sprint review with some cake.
We visited Cartem’s Donuterie recently for a post-sprint celebration treat.
But, scrum was originally created for a team of developers. So the question is:
How does the entire team — designers, product owners and managers, and customer-facing team members — work within the scrum framework?
Here’s what we decided to do:
We split the sprint work into different phases where the whole team, not just developers, contribute to the feature development:
Step #1: Research (I do this in advance of the sprint)
I meet with the product owner, product manager, developer and a member of the customer team to review competitive research and direct user feedback we have received. We all rely heavily on an amazing tool called Productboard, which we highly recommend for organizing and prioritizing feedback from your users.
Step #2: Brainstorm (Again, done in advance of the sprint)
Based on the research and user feedback, we write down user stories, which summarizes who the user is and what the requirements are for the feature, and agreeing upon acceptance criteria, conditions that must need to be satisfied by the end-users. Acceptance criteria also plays an important role as written-down agreement on what need to be done for the team. The key role of the designer during this phase is to keep everyone focus on the right topic away from too much ideation.
Step #3: Sketch (Ideally, this is done ahead of the sprint as well)
Now this is the time for me to login to InVision and get to work. I love their new feature, Freehand; a simple solution for my site-mapping need. Once the sitemap successfully reflects all acceptance criteria, I move to Sketch for wireframing and high-fidelity design. I involve the product owner for each design stage to ensure we’re on the same page and I haven’t missed anything. Remember: a designer’s job is not just about working with color and pixels. It’s also to communicate product vision to the team.
Step #4: Develop
Developers are always involved in planning phases, therefore making this transition easier and faster. But, make sure you sit in the same room and go through the prototype as many times as needed to be on the same page. If there are disagreement or outstanding concerns that need further discussion, bring out the acceptance criteria and iterate with product owner.
Step #5: Test
The sprint isn’t complete without going through a complete checklist of test items. Are the buttons working? Does the screen redirect correctly? Acceptance criteria comes in again to play an important role here. Test each AC items. Everything has to work the way it was discussed. Be friends with developer and copywriter. They worked hard on the feature, too, so be mindful of that. (Don’t be a mean cat.)
Are there new findings that need to be fixed? But, they aren’t on the list of acceptance criteria? Don’t panic. Quickly discuss the scope of the fix and decide whether to address it now or later.
Step #6: Learn
This is where I haven’t successfully bought everyone in. Scrum can be rigid, especially on 2-week sprint cycle, so I struggle to find time to fit in data analysis, to user test and to explore feature enhancements.
As you can see, we do the research, brainstorming, and sketching at least one sprint ahead of time. We decided to take this approach to help the developers more accurately estimate the time needed to complete their work. It’s therefore my job to work with the product owner to get the feature sprint-ready for them, so they could dive right into it at the start of their 2-week sprint.
Step #7: Validate the processes with the whole team as frequently as possible. Keep the topic open for discussion at all times.
Giving feedback is fun.
Step #8: Keep record of feedback and be open-minded
Step #9: Be ready to adapt
What I’ve shared here isn’t a perfect process in itself. And whatever process I’ve outlined above has probably already changed by the time this blog is published! Process involves ongoing collaboration with your team. I think the key is to keep your process as flexible as it can be.
If this story sounds similar to what you might be going through at your growing startup, leave a comment below. I’d love to engage in an honest discussion and learn what you are doing!
If you’re in the Vancouver area… come to our upcoming meet up: “Designing Process” on Thursday Nov 2, 2017, 6 p.m.
We’ll be discussing what it is like to be a startup designer working in tandem with an engineering scrum team. Email firstname.lastname@example.org if you’re interested in attending!
Thanks to Suzanne Ma.