Developing the Rypple Service

We think of ourselves as a services company here at Rypple. Our goal is to provide you with an awesome and complete experience, so we a take a page from Izzy Sharp, one of our Canadian idols, and “make customer service everybody’s business.” Here’s an example that got me really pumped. Daniel received a direct message via Twitter from Dilyan Damyanov. Dilyan told him that sharing feedback via email did not work as expected. Cyrillic feedback content did not show up properly in recipients’ inboxes after he’d shared it. Daniel immediately let me know and after some investigation, discovered that the problem was the email character encoding. I quickly resolved the issue, sent it to production, and asked Dilyan to approve the fix. We resolved Dilyan’s issue within the same day! That’s what I call a good day at the office!

I learned some key lessons from this:

• There is no substitute for User Interaction. We listen to our users, ask them for feedback, and acting on it. Design considerations always prove incorrect in the field, despite how smart you are, so you need to pay attention to users like you.
• A Social media footprint is critical. Our team is active on blogs, Facebook and Twitter and use these tools to quickly connect with and talk to our users.
• Agility adds immediate value. The ability to quickly respond to changes (feature requests or bug reports) is essential for an agile team. Customer collaboration, responding to change, and individual interaction are key agile values.
• Highly cohesive and modular code rocks! I traced down the problem quickly and made a simple change because all email sent from our system goes through a single nexus.
• It’s vital to release to production often. Working software is another core agile value and it’s great to be able to introduce a quick update into a production environment to resolve an issue.
• Fail early and fail often. A great way to master learning is through getting feedback, reflecting and acting upon it, and then starting this cycle early and repeating often. XP (extreme programming) takes this to heart.

We could have spent ages imagining how you might use the share-via-email features. Instead, we created a simple share feature, and after it went live, we made a few improvements based on user feedback and usage patterns. Some of that feedback even suggested novel ways of how sharing could be even more useful. It would have been hard for us to think of those novel uses because that is not how we would have used Rypple ourselves.

This whole experience has me really pumped. I was once on a team that introduced agile development into a company by taking lessons from Poppendieck’s excellent book Lean Software Development. While looking for sources of waste that we could eliminate, we discovered that it took over 100 days for a user like Dilyan to approve a fix for an average bug! We were astonished but we eventually cut that time in half.

I hope you now understand why delivering a working fix within a day has me really excited. Guided by user feedback, we surely and steadily evolve Rypple. We see our work having immediate impact. This is truly rewarding and that is why I love working for a user-focused and service-oriented software company.