Transforming organizations
As a product designer at Devbridge, I’ve had the privilege of solving software problems for a variety of industries. Our clients frequently turn to us for support because they:
Lack established product teams and their business stakeholders are working directly with engineering.
Do not have in-house designers.
Do have in-house designers, but their impact is minimized because they are downstream from the product decisions.
Companies hire us because of our speed of delivery and our expertise in respected schools of thought, such as agile, design first, and product thinking. One key ingredient in our recipe for success is our product teams. Roles on a product team vary by company, but in our case, our teams include product managers and product designers.
Our product experts partner together to:
Gain insights and requirements from the business and end users.
Iterate to find the best solution.
Work with engineers to build.
Unfortunately, some client's ineffective team structures mitigate their success and perpetuate the very problems they’re hiring us to solve. In order to fully embrace transformation through software, organizations must be willing to make changes in how teams function.
In this article, I’ll share three do’s and don’ts for organizations seeking to take on a healthy product focus.
DO: Adopt a product mentality to run more effective teams.
DON’T: Believe product thinking can be purchased and not maintained after the product release.
Let’s say you have a software need but internal resources do not have the expertise or allocation to take on the work. Therefore, you hire a vendor like Devbridge to build the software for you. After some lean requirements gathering, user research, and design iteration, the engineering team is off and running. Soon, you have the shiny new product you needed. High fives all around. Project complete, right? Well, not really.
Just because the product is released doesn’t mean it won’t need continuous improvement. When a product is maintained the same way as legacy applications, it is destined to become another legacy application. Without internal change, you’ll be continually outsourcing your problems to someone else without truly innovating.
Consider this metaphor: Suppose you want to get into shape, but you’ve never exercised. One option you have is to hire a personal trainer to show you the ropes on fitness. Let’s say you have limited funds and, since trainers are expensive, you decide to work with a trainer for three months.
Things with the trainer go swimmingly. After three months, you have indeed hit your goals. You bid your trainer adieu, certain you can stay fit on your own. The only problem is, without the trainer’s guidance, you stop exercising and slip back into old habits. In the end, money and effort are wasted because you haven’t truly changed your behavior, you’ve just purchased a service.
Wait, why am I on this mat again?
Of course, this isn’t the only way the story can end.
Working with a product consultancy is similar to hiring a trainer. You can bring in experts to help you get where you want to go, but you’ll need to change your behavior to see continued results.
DO: Involve design in the requirements gathering process.
DON’T: Treat design as a coat of paint to what the engineers build.
An effective product designer has the responsibility and expertise to look at nebulous business requirements holistically, and turn them into a straightforward, thoughtfully architected user interface. Unfortunately, it’s not uncommon for business requirements to get handed to engineering directly, with “just in time design” adding some visual interest as an afterthought. We have all these brilliant engineers, right? Do they really need a designer to hold their hand?
The truth is, it’s not about hand-holding. Wouldn't it be great if engineers had time to think through all the business implications and end-user needs before embarking on their work? Would it be faster if engineers were experts in usability and pros at creating effortlessly beautiful interfaces? Yes, but that's not reality.
Your engineers are not designers. They have a different focus and skillset. If you forget that, you put your engineers in a conflicting position. The fastest or simplest solution to code isn’t always the best solution for the product’s audience, but there are deadlines to hit and more work to do. Something has to give, and teams rarely want to sacrifice output.
You can avoid this scenario. Make sure someone (aka the product team, and specifically, in this case, your designer) is thinking about the product’s overall goals and takes that responsibility off engineering. Product teams should sit between engineering and the business to ensure the right thing is being built. The product team will work with clients to gather their requirements and with engineering to translate requirements into working code. The risk of not adopting this approach is a suite of products that cater to engineering maintainability and not to the needs of the business. No modern organization should have its technology confining their business goals.
_
Appropriate team structures lead to thoughtful, quality work._
DO: Make sure users will benefit from the product you’re building.
DON’T: Underestimate the perspective of your end-users.
We’ve encountered many project stakeholders who may well be the key decision makers. However, they don’t understand the merits of talking to their end-users. After all, the users aren’t footing the bill, right?
Well, let me pose this question: Why is technology worth investing in without considering the people using the technology? The end-users and the product are intertwined. Both are essential entities to whatever business problem you’re addressing. In the end, the product is a productivity tool. The coolest, slickest software product in the world won’t be useful to anyone if it doesn’t make the job easier; it is only as effective as the people using it.
Dear god, what have we done?
So instead of guessing at what your users need, ask them. It doesn’t have to be expensive. Most users are easily available (in the context of enterprise applications), and willing to share insights that you wouldn’t have anticipated. Without talking to users, you risk wasting money and resources on something ill-fitting and counterproductive. Wondering who would take on the responsibility of talking to users? The product teams. Nicely done.
Do know change isn’t easy, but it can be done!
Organizations that are lacking in product teams or appropriate team structures aren’t going to magically sprout them overnight. Let these insights offer a starting point for understanding how product teams contribute to success. Avoid these pitfalls, and your organization will be well on its way to building successful products.
Technology by itself is not the key to success. Mindful commitment to change will ultimately lead to higher quality and innovation.
