Being vulnerable enough to innovate.
The world-renowned researcher Brené Brown once said, “Vulnerability is the birthplace of innovation, creativity, and change.”
So here’s to being vulnerable… I work for a company called Originate as the Director of Product and we are in the business of innovation. We are a technology services consulting firm working behind the scenes with some of the world’s biggest brands and well funded start-ups. And guess what? We have the best and the brightest folks from the top computer science and business schools from around the world, with resumes that would make your eyes pop, and we still make mistakes. Why do we make mistakes? Because we take risks, and without taking risk there is no innovation.
Now, I have been working in product management for a long time, over a decade actually. I have seen my fair share of what works and what doesn’t, and I have also made my share of mistakes along the way. So with this article, I would like to be a bit vulnerable. I want to give you a peek under the hood of an innovation company and share with you some of the mistakes we have made, and learned from.
At Originate, we find ourselves in an interesting situation. Many of our clients come to us after being burned by previous technology firms. Some of our clients have tried doing the “off-shore” thing and it didn’t work out. Others may have even spent millions in development only to find out it’s a garbage application. We sometimes are the last resort for many of our clients, looking for someone to solve their problems that no one else could. Our four-pronged approach through product, design, engineering, and quality assurance allow us to maneuver and innovate in a way that most technology firms cannot.
That being said, I would like to focus on three mistakes we have made in the past, what we learned from the experiences, and how you can avoid making the same mistake.
User Research Pays Dividends
I am in the business of building software. And with that, I am responsible for our Product Management efforts at Originate. When building software, a crucial component of the process is gathering requirements, or in other words, knowing what you are going to build and why.
There are certain steps we can take to ensure our requirements are validated, but sometimes we are pushed to build software with no validation on requirements at all.
“Sometimes high-level executives, we’ll call them stakeholders, come to product managers and demand for features they want to build, but they have no research or validation to back up their claim. “
The stakeholder just wants the feature built because it is a priority for them. I personally have been guilty of building software features just because a stakeholder wanted it. But the truth of the matter is, just getting requirements blindly from a stakeholder with no data or research to back up the claim sometimes leads to false positives and the feature ends up providing no added value.
A better approach, and what I recommend, is setting the stage with stakeholders, at the beginning of a project, on the process for requirement gathering and consulting them on the necessity of working directly with users to get feedback. This user feedback loop helps product managers, designers, and engineers, have validation to the requirements, which should be a continual part of the software building process. If you have been here, you know it’s so easy to fall into the trap of building a feature because the stakeholder wanted it, only to find out later the user has no need for the feature.
I cannot stress enough the importance of user research! I am not saying you need to produce a research paper worthy to publish in a journal for each requirement, but you can collect qualitative or even quantitative data from users that provide plenty of directional, or statistical power, to feel confident in your decisions. It may seem like an extra step in the building process, but trust me, user research pays dividends!
Nobody Wins with a Fixed Bid Contract
There are a variety of ways to create a contract to deliver services between a technology consulting firm and a client. One of those ways is called a Fixed Bid contract, which essentially is a fixed fee amount the client pays, regardless of hours spent developing the application.
And in my experience, Fix Bid contracts often cause misalignment of interests between the technology consulting firm and the client. Instead of both companies working together to prioritize the features to be delivered, it becomes a race to not run out of money. The client wants to squeeze in as much as they can, and the technology company tries diligently to honor the client’s request while managing a finite amount of time. Often times, this ends up feeling like you’re watching sand disappear from an hourglass.
To make matters worse, because of risk and complexity, it is nearly impossible to provide an exact completion date and hit that completion date on time. Once the contract time runs out and the project is not completed, the risk shifts completely over to the development company. Fixed Bid contracts fundamentally don’t match up to the agile software development framework. Estimates change and so do priorities. Fixed Bid contracts do not provide the flexibility that an agile development process requires.
A better way is to use a Time and Materials (T&M) contract with clients. This allows for both parties to share in the risk equally. It also provides an environment to focus on prioritization and aligns well with the agile process. I highly recommend using a T&M contract with your clients, you won’t regret it!
Building as Fast as You Can isn’t Sustainable
Product managers live in a world of timelines and budgets. I am definitely guilty of trying to push development as fast as humanly possible in order to meet a client’s expectation for a delivery date. But the truth of the matter is: compressed timelines for project deliveries don’t allow for proper alignment within disciplines (product, design, engineering, QA), and the hand-off between these disciplines can become highly error-prone.
When timelines for projects are too short and compressed, hand-off between product, design, and then over to engineering becomes messy. It is crucial that product has enough time to conduct user research, gather requirements, write user stories, prioritize, work with design on UX/UI, and then hand-off to engineering for development. Focusing on a sustainable development approach helps to develop a consistent delivery pattern, and helps to eliminate burnout with developers. When developers are overworked and exhausted, they are not performing at their peak.
Building software is about solving complex problems. This process sometimes cannot be rushed. It takes time to build software that is elegant and handles user experience in a graceful manner. Also, throwing more developers at a problem trying to be solved often doesn’t lead to desired results. Focusing on development sustainability will give your developers room to breathe and time to solve the complex problems.
In summary, innovation is not a destination, it’s a journey. Along that journey, we sometimes make mistakes, but we always learn from them.
Remember:
- User research always pays dividends. Building a product towards what customers actually want and desire is a winning formula.
- Be thoughtful in the contract you select with a client or with a technology consulting firm. A contract can make or break your project, but a Time & Materials contract shares the risk and creates an environment to prioritize correctly.
- We all want to cross the finish line first, but when organizations work together to be innovative, the focus on a sustainable development approach is key.
Lastly, it’s ok to be a little vulnerable. Navigating the waters between clients, contracts, and disciplines to build a production level application can be difficult, but it’s possible. And with the right team, you can even have some fun along the way!
