Some choices in life are easy. Coffee or tea? Tea, please.
But the choices you face as a software developer are a little harder. Jocelyn Goldfein, former Director of Engineering at Facebook, joined us on the second episode of FemgineerTV to talk about how to make smart tradeoffs in the name of happier customers and smoother product development.
If you haven’t seen the episode yet, you can watch it here!
At the end of the episode, we gave viewers a challenge: We asked them to write in and tell us about the last tough tradeoff they had to make when creating a product.
We’re happy to announce three winners from the challenge!
Lawrence De’Ath ran the risk of losing his biggest and best customer when faced with a decision to change his plans for a locally installed product into an SaaS product.
Madhavi Arsoor had limited time: she could either spend it improving the UI of her blog or creating useful content for her readers.
Theron James debated whether to rewrite an iPhone app in familiar Objective-C, or do a retool and rewrite by having his team learn Swift first.
So, what did they choose? Here’s how it played out.
Lawrence’s tough call: Please an existing customer or serve more customers?
Lawrence De’Ath’s team was debating whether to build their offering into a locally installed software product or go in a new direction and develop an SaaS product, which would be easily accessible to customers online.
His challenge was that his top customer was keen on a locally installed product.
But this would be more expensive to develop. What’s more, when he thought about the larger group of his potential customers, he realized that an SaaS product would serve them better. They’d save time because they wouldn’t have to install a local version, and it would be easy for them to try a product demo.
“The risk was that the client would think we weren’t committed—or perhaps not able to develop an installed product. We chose to develop an SaaS product and begged our top customer to be patient. We presented it as a prototype we would all learn from,” Lawrence explains.
Once Lawrence chose to develop an SaaS product, he stepped back to see the results.
“The end result was that our top customer saw our progress in building the SaaS prototype, and other customers liked what they saw and wanted us to build out the SaaS prototype. We learned to hold our ground when the development process was right but didn’t fit exactly what the customer had in mind.”
As you can see from Lawrence’s story, it’s easy for us to make tradeoffs based on the limitations of our technology, but as Jocelyn Goldfein explains in her interview with FemgineerTV (above), we get the best results when we also consider our customers’ needs.
“Different technology stacks lend themselves to different solutions. But it’s not a technology-driven decision alone,” Goldfein says. “We need to think about what matters most to customers and what their expectations are for your product’s benefits.”
Madhavi’s time constraints: Improve her blog UI or create more content?
Madhavi had limited time to dedicate to her blog, and she wanted to create new content but also had to figure out whether she should spend time improving its UI.
“My recent tradeoff was to allocate my time between building a great UI and creating useful and valuable content for my blog readers,” she explains. “The more we work on features the more we think of, and the to-do never ends. I had to decide between improving the appearance of my blog and adding additional content. The risk was losing more visitors due to the look and the feel of the site.”
So, what did she do?
“I returned to my my mission to deliver great content, and decided to spend some time on UI to make it appealing enough to convey the message I wish to convey. Without content, a great UI is of no value to my audience, but I wanted to make sure the UI was aligned with my message, so that I could focus more on creating content.”
When she got feedback from her readers, they said that they placed more weight on the blog content than the UI. They liked her new look and easy navigation, but were more interested in the content than the blog’s look and feel—as long as the UI didn’t hinder their experience.
“I’m now back to creating more content based on feedback from my readers, and when I have time, I’ll enhance the UI of the blog to improve the reader’s experience.”
Theron’s choice: Rewriting and retooling an app at the same time?
Technical debt is inevitable, and it can be hard to convince your team to take time out to do a rewrite.
Theron James had to make not one, but two tough decisions!
The first was the decision whether or not to do an app rewrite. He did a cost comparison in terms of the current technical debt’s impact on speed to market. It was taking his team three months to go from idea to market. Investing that time in doing a rewrite would make it so that they could build in two to three weeks instead of three months. Paying off the technical debt would speed up development time.
Whenever there’s an opportunity to rework, there’s also a temptation to try something new. . .
Theron and his team were intrigued by the idea of using Swift. They debated whether to learn this new language for the app rewrite, or stick with the language they were familiar with: Objective-C.
They knew that retooling and educating the team on Swift would take longer. Ultimately, they decided to stick with Objective-C.
“Although we were very excited about the prospect of Swift, given the tooling resources and team knowledge, we went with Objective-C. This has proven a good choice,” says Theron.
He continues, “Before we began the project, I shifted everyone from the management triangle of scope, cost, and schedule to an Agile Triangle of value, quality, and constraints (scope, cost, schedule) where we use the constraints to focus on two core values: quality and value (i.e., customer delight).
“As we were doing the rewrite, we ran one week of sprints/iterations. We’d make mistakes but then take the time to learn from them and make corrections. Taking this approach meant that the cost was rarely ever more than a week’s worth of effort.
“We used behavior-driven development (BDD) to identify the largest areas of risk. This helped us prioritize the features with the greatest risk first.”
Decisions that delight customers
Each of these viewers had a tough call to make and they took the time to evaluate their options. They considered the technology they were using, the business model they were operating under, and, importantly, their customer’s needs.
Goldfein agrees that delighting customers is key. “We have to be motivated by the person using our software. We have to remember that we cannot do everything in the world we’d like to do, so we should do what matters most to that person. When we design for the person, we do our best work.”
Want to participate in the next viewer’s challenge? The third episode of FemgineerTV airs in April. I’ve invited Ryan Hoover and Erik Torenberg, the founders of Product Hunt, to talk about: How to Build a Community of Evangelists for Your Software Product. Subscribe to our YouTube channel to know when it’s out!
FemgineerTV is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Category: BuildTV
