We’ve got a great team at Rival IQ, and to give you a sense of our team flavor, we’re going to start featuring writing from all our various characters — even the engineering team! This week, we hear from one of our co-founders, Seth Bridges, about how we’re constantly improving the product development process by continually looking inward. Even if you aren’t a developer, we bet you’ll learn from our experience.
Our team has a joke that comes up pretty often when we’re in the middle of a development sprint.
“The first 80% is done. Now, for the last 80%.”
Someone usually utters this comment after we have our new features “working” end-to-end but before we’ve applied any polish to how it all works. For a longer period of time than I’m comfortable admitting, the last 80% was pretty painful. We would get down to “polishing,” only to find ourselves asking questions like:
- Is that really the word we want to use to describe that button?
- You have to click what to finish the process!?
- What do you mean, I can’t do that — that was the whole point!
Do you see the problem? These kinds of questions should have been asked and answered much earlier in the process, say during design, and not when we were trying to polish the details.
It turns out that skimping on the early-stage design process yields a less good outcome costing more time than if we had invested the energy earlier. At this point, you may be saying, “Yeah, sure, you’re idiots, of course skimping on design doesn’t work that well,” and you may be right (about us being idiots); however, I think that our specific failings are less about general axioms regarding product development and more about something that applies to anyone working in or managing a team of people. That is, any misalignment between the passions of your team and the work that must be done will likely lead to subpar results if not managed appropriately.
For example, our development team at Rival IQ is full of rock stars (if I do say so myself), but no one whose primary passion is UX design. We’re certainly all excited about back-end services, database, ops, and scalability, but the gap on our team, UX design, is directly related to our struggles with nailing our features the first-ish time. I guarantee you that a different team with players who had more UX focus and less back-end expertise would find challenges in some other areas like data ingestion, performance, etc. Regardless of your specific team composition, shorting any part of the product development process will result in a product with a non-zero suck factor. And no one really wants to churn out a crappy product, right?
Punching Weakness in the Face
Fortunately, there are lots of ways to develop better products and improve your process at the same time, all of which require some sacrifice, be it ego, time, or money. I’m sure the list is much longer than what I’ll share, but here are some things that we have done to deliver a better product, faster.
1. Review what went well and what didn’t
At least every two months or so, take the time to review how your sprint went. I’m sure there are agile or scrum process fanatics who say that retrospectives should be a part of every sprint, but you need to find what works for your team. Regardless of the frequency, formally recognizing the retrospective process is important because it forces you to answer specific questions around which processes need work and which should continue. Additionally, setting up the formal time to do it with full team participation (including stakeholders such as marketing) has the added benefit of encouraging input from all parties who may be less inclined to share in a more ad-hoc manner.
At Rival IQ, we tend to have sprint retrospectives around every fourth sprint, and every time we have the conversation, I feel like we get our process (or lack thereof) a little bit more dialed.
2. Know your team’s weaknesses
No one really likes admitting they suck at something. Also, no one really likes working on things they aren’t good at, either. That said, your team will perform better and grow their skills over time if each individual has a good awareness of their weaknesses. As a manager, knowing the types of work that your team doesn’t like to do because it doesn’t align with their passion or skill is the first step in mitigating your skill/need gaps. Take the time to consider your own weaknesses and those of your team. I find it easiest to ask myself, “What work do I always postpone to focus on something else?” Whether at the office, at the gym, or anywhere else, the answer always highlights a personal weakness.
3. Be ruthless about scheduling time to fill gaps
Once you identify where your weaknesses lie as a team, your only hope for success is to attack your deficiencies by ensuring problem areas get focus from specific, named members of your team — and that time for work on these areas is appropriately scheduled during the sprint. Just putting on the schedule that Bob is going to do “Yucky Thing X” without giving him ample time to do the work means Bob will just de-prioritize the task, and do some other work that he likes better. In the end, you’re no better than if you had never even assigned Bob the work. By clearing the decks for Bob, you are removing distractions and setting him up for success.
At Rival IQ, we’re (now) generally good at scheduling ample time for feature design, often a sprint ahead of implementation, along with a general agreement that fewer features delivered with higher quality is better for our customers and better for our team. The key thing to note is that we didn’t start with that view. We’ve learned these lessons (from our mistakes), together with each other, over the last 20+ months of product development.
4. Know when to get help, even if it costs something
Sometimes, your best efforts still won’t cut it, and hitting this kind of wall is normal. Realizing that all the time in the world isn’t going to let you overcome a weakness means that you need to attack the problem in a different way whether hiring, begging, borrowing, or stealing (figuratively, of course).
You’d never guess (ha!), but one weakness (of many, I’m sure) we have as a team that we won’t ever overcome with our current staff is graphic design. It just isn’t in any of our DNA, but we’ve made the best of the situation by leaning on external design firms for help with art and graphic design tasks. Sure, it costs us money to hire external help, but the alternative is worse. Can you imagine what our site would look like if our database person started doing our graphics? Exactly, so find a way to make it happen. (No insult intended to any graphically inclined SQL wizards out there.)
I’m happy to say that I’m part of a team that is humble enough (previous comments regarding rock star status notwithstanding) and driven enough to be able to make weekly improvements in how we build software together. Chances are that the team you’re a part of a team that could stand to improve, too. So the next time you get the chance to suggest improvements in your own process, don’t be shy, and push for things to get better.
