By Poornima Vijayashanker
When you woke up this morning you probably got out of bed, and had to decide on what to wear (unless you have a uniform..), how to do your hair (if you’re like me and have a pixie cut it’s easy!), and then you were off to work or maybe you took the day off, whoohoo!
As you go about your day, you’ll notice that people will come up to you, and ask you to choose between one or many options.
Sometimes the choices are easy: “Coffee?” “No tea please!”
And sometimes the choice are hard: “Donut?” “Hmmm…” “Chocolate, glazed, cake…?” “mmmmmmm!!”
When you’re faced with tough decisions, you end up evaluating the tradeoffs to the best of your abilities. Sometimes it works out, and sometimes it doesn’t… “Why did I eat that donut?!”
3 week ago we aired the second episode of FemgineerTV with Jocelyn Goldfein, and we talked about How to Make Smart Tradeoffs When Building Software Products. If you haven’t watched it yet, then I highly recommend that you check it out here!
At the end of the episode we posed a viewer’s challenge. The challenge was to share the following:
- What was the last tradeoff you had to make?
- What was the cost of the mistake?
- And how did you or your company feel about taking the risk?
Winners from the challenge!
Lawrence De’Ath had to make a tough call: developing a product to please an existing customer vs. changing their product to attract more prospective customers. He ran the risk of losing his biggest and best customer!
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 had to decide between doing a rewrite and retooling at the same time. He needed to rewrite an iPhone app and was debating between rewriting it using a language that his team already knew: Objective-C or having the team learn Swift and then do the rewrite.
Making Tough Decisions: Pleasing an Existing Customer vs. Serving More
[quote author=”Jocelyn Goldfein”]Different technology stacks lend themselves to different solutions. But it’s not a technology-driven decision alone.[/quote]
It’s easy for us to make tradeoffs based on the limitation of our technology, but as Goldfein says, “We need to think about what matters most to customers and what their expectations are for your product’s benefits.”
Lawrence was presented with this situation. His team were debating on building a locally installed product versus a saas product easily accessible to customers online.
His challenge was that his top customer was keen on a locally installed product. It would be more expensive to develop it.
But he was pretty sure he wanted to create the saas product, because he could reach more customers, demo the product easily, and save them time by not having to install the software!
[quote author=”Lawrence De’Ath”]The risk was that our best customer would think we weren’t committed – or perhaps not able to develop an installed product. We chose to develop a saas product, and begged our top customer to be patience. We presented it as a prototype we would all learn from.[/quote]
[quote author=”Lawrence De’Ath”]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 learnt to hold our ground when the development process was right but doesn’t fit exactly what the customer had in mind.[/quote]
Constrained By Time: Improving the UI vs Creating More Content
[quote author=”Madhavi Arsoor”]My recent trade off was to allocate my time between building a great UI and creating useful and valuable content for my blog readers.The more we work on features the more we think off and the to-do never ends.[/quote]
Madhavi had to decide between improving the appearance of my blog, and adding additional content.
The risk she was taking was losing more visitors due to the look and the feel of the site.
Madhavi returned to her mission: to deliver great content, and decided to spend some time on UI to make it appealing enough to convey her message.
[quote author=”Madhavi Arsoor”]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.[/quote]
[quote author=”Madhavi Arsoor”]The feedback that I got from readers was that they like the new look and easy navigation. They are more interested in the content than look and feel as long as the UI doesn’t hinder the user experience. The readers place more weight on the blog content, than the UI.
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.[/quote]
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 had to make not one but two tough decisions!
The first was the decision to do the rewrite. He did a cost comparison in terms of current technical debt’s impact on speed to market. It was taking his team 3 months to go from idea to market. Investing that time in doing a rewrite would make it so that they could build in 2 to 3 weeks instead of 3 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 excited about the prospects of using Swift. They thought about doing the app rewrite using it versus the language the team already knew: Objective-C.
However, they knew that retooling and educating the team on Swift would take longer.
[quote author=”Theron James”]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.
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 2 core values: quality and value, i.e. customer delight.
As we were doing the rewrite we ran 1 week sprints/iterations. We’d make mistakes but then take the time to learn from our mistakes and make corrections. Taking this approach meant that the cost was rarely ever more that 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.[/quote]
Decisions that Delight Customers
Each of these viewers had tough decisions to make, and took the time to evaluate their options. They considered the technology they were using, the business model they were operating under, and considered their customer’s needs to make decisions.
[quote author=”Jocelyn Goldfein”]“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.”[/quote]
Want to participate in the next viewer’s challenge? Subscribe to our YouTube channel to know when the next episode of FemgineerTV will be out. We’ll have guests Erik Torenberg and Ryan Hoover from ProductHunt on the show to talk about How to Build a Community of Evangelists for Your Software Product.