Get Out of Your Own Way: Top 3 Developer Tips for Customer-Focused Products

Chantal Botana

Global Head of Cognitive Products & Emerging Platforms, The Weather Company, an IBM Business

The Weather Channel & Samsung Design Thinking Workshop - Pictured Left to Right: Eric Christianson (TWC Android Engineer), Chang-Ryeol Song (Samsung Product Manager), Tabish Mufti (TWC Android Engineer), Shriyas Gopad (Samsung Android Engineer), Kevin Crenshaw (TWC Android Engineer), Denise Francis (TWC Product Designer), Bethany North (TWC Product Manager), Kevin Kim (Made for Samsung Product Leader), Chantal Botana (TWC Product Leader). Not Pictured: Swapna Raju (TWC Quality Assurance Lead)

As the Global Head of Cognitive Products & Emerging Platforms, The Weather Company, an IBM Business, I have seen my fair share of developers work through design and implementation challenges, and I’m going to share some insights to help get you out of the deliverables game and into customer-focused outcomes:

  1. Make Sure You're Not Suffering from Cross-Function Dysfunction You've bought into the agile philosophy - or at least you think you have. You've done the training. You or your organization has employed several agile tactics, and has perhaps hired an agile coach or two. Now check yourself or your organization to see if you're truly independent and cross-functional. Does your product development team consist of a product lead, one or more product designers, two or more front-end developers, a couple of back-end developers, QA and DevOps - or better yet full stack engineers? (Give or take a few people - let’s not forget the “two-pizza rule” courtesy of Amazon’s Jeff Bezos). If you’re not truly cross-functional, your work is inevitably siloed and your customer outcomes are suffering from organizational dysfunction. Without a doubt you’re spending more time trying to get your requests prioritized on someone else’s backlog based on totally different KPIs than your own. Having all of the critical people 100% dedicated to your mission is a must. Now, if you're in startup mode where you’re wearing many hats and having even one person from each other cross-function is a luxury, you can at least find comfort in the fact that you’re only waiting on yourself. Sometimes that’s better than waiting on someone else. Really, there’s nothing worse than the “hurry-up-and-wait” game.PS: For a good read on getting out of the hurry-up-and-wait-game read or listen to “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” by Gene Kim, Kevin Behr and George Spafford.
  2. Stop Admiring the Scrumfall Problem and Rope Yourself Into Ideation. Do you find yourself waiting on product requirements to ramp up your contribution? If so, let’s call a spade a spade and admit that you’re just waiting on someone to enter one or more JIRA tickets that trickle down a bunch of to-dos in a Scrumfall fashion (scrum + waterfall = Scrumfall). At the risk of showing my age, I've never heard any developer say they miss PRDs (Product Requirements Documents) - or more to the point, being told exactly what to build - though admittedly under-documentation can be an equally frustrating problem in the world of Scrum and Kanban. While there's certainly a happy-medium to be found between documentation that no one reads and verbal communication that falls on deaf ears, the best way to unleash your creativity is to be part of the ideation at the onset. So, if no one’s inviting you to upfront ideation, then take it upon yourself to demand a seat at the table. As a developer, you are most certainly a creative, and you need to unleash your ideas, in a collaborative way, before the solution is handed to you. Be vocal about participating in the “Discovery” phase of every product &/or feature. When it comes to product discovery, I like to use Jeff Gothelf’s newly adapted version of the Business Model Canvas called “Lean UX Canvas”. To quote Jeff, he uses the canvas process “to help teams frame their work as a business problem to solve (rather than a solution to implement) and then dissect that business problem into its core assumptions.” Assumptions are then turned into hypotheses, which are in turn made into lean experiments to test the riskiest hypotheses. If you’re a lone developer building your own app, this is a great tool for you, too.
  3. Participate or Facilitate in a Design Thinking Workshop. Whether or not you’re wholly independent (Tip 1) or part of a discovery team (Tip 2), you and your organization can still reap the benefits of putting your customers first by leveraging Design Thinking. Stanford Business School offers a four-day hands-on workshop, but it ain’t cheap. If you have the time and the money to dedicate to higher-education training, who wouldn’t want Stanford d.school on their résumé. A highly-qualified FREE alternative option is IBM Design Thinking. You can learn about “the guiding principles” and “the loop” at your own pace:

Guiding Principles

  1. Focus on user outcomes
  2. Relentless reinvention
  3. Diverse empowered teams (there’s tip 1 again)

The Loop

  1. Observe
  2. Reflect
  3. Make

In full disclosure, I work at The Weather Channel, which is an IBM business. I’ve been through internal training myself, as has the cross-functional development team, and we really do practice what we preach. As part of the Made for Samsung program, I invite the Samsung team every quarter to a Design Thinking workshop for partner collaboration with the cross-functional team, giving everyone an opportunity - including customers themselves - to solve the problem at hand by thinking in new ways.

If you’d like to join the conversation, tweet us at #ConnectedWeather and you’ll be put in touch with the proper The Weather Channel or IBM contact.

Register for SDC2017 today