People, Process and Product: Building Innovative Telemedicine Technology
Sean Banerjee, Chief Technology Officer at SOC Telemed (SOC), is a technologist and a healthcare product simplification evangelist with more than 20 years of IT leadership experience in leading large IT software engineering shops in multiple successful healthcare tech startups and growth ventures. He explains the three aspects of leading high-performance and innovative development teams: People, Process and Product.
People–Building the Team
The right group of people will build the best processes to get the work done. With the right people and the right processes, it is much easier to build innovative, high quality products that bring value to our clients.
It is a challenge to hire the right people. It can take months to hire a top-tier candidates. We go beyond the technical and intellectual qualifications to also evaluate the soft skills required:
- Are they open to new ideas?
- Do they have the ability to explain and simplify the complex?
- Can they demonstrate creative problem-solving?
At SOC, we have a collaborative environment that encourages open and vigorous debate. The best ideas take shape that way; the team is always smarter than one person. Our process is very democratic – the most reasoned and logical ideas move forward. You know you are successful when you leave a meeting with the smartest way to solve a problem and you can’t remember who had what part of it.
Process–Getting it Done
Process is a simple concept but it causes a lot of problems in projects. Whether you are building a house, a bridge, an airplane, or software, the process enables your success. There are several important considerations you must address to ensure high quality products and solutions.
- Start with Good Bones. Without a good structure, or “good bones”, what you build won’t hold its own weight. You must think about scale from the beginning of the process. With each additional feature you add, your product grows. Will your framework support it?
- Build in Phases. You must build the product in phases, starting with the “minimum lovable” product that meets the minimum viability requirements. Then, you add more functionality in planned phases throughout the life cycle of the product. A complex product generally needs 3-5 years of continuous development after the initial release to users to reach the saturation stage – there is no way to do it all in one step, or in one or two years.
- Hold the Door. Even with all stakeholders in agreement, there will be enormous pressure for scope creep and changes to the project. You must hold the door! Every change has an impact on scope, time, or resources. Scope creep can be demoralizing to the team. If they lose hope and trust in management they may decide to leave the company. As the leader, you must take the brunt of the pressure for your team.
- Don’t be in denial of the color. Many project plans include colors to represent whether things are on track (Green), have experienced some delay (Amber), or have completely derailed (Red). You can never be in denial of the color of any part of the project. Communicating promptly to your team and leadership is essential to maintain trust. In other words, if your car starts swerving into another lane, you immediately bring it back into your lane; you don’t wait for someone else to notice and beep. Communicating delays or issues can lead to some tough, stressful meetings. But, if the trust is there, and you can explain why, and provide options for a ‘path to green’, people will listen. Remember, nobody wants a failed project, everybody wants the project to be successful. Either re-scope, or give it more time, or put in more resources – there are only three ways to bring the project back on track.
Product–What to Build?
- Start with WHY – Understanding the Requirements: When beginning a new telemedicine platform project, our development team spends a great deal of time understanding the problem we are trying to solve. This starts with interviewing customers, potential customers, and industry experts to understand the nuances of their pain points. Many projects fail or get delivered late NOT because of bad coding by the developers, but because requirements were not correct at the onset, the right questions were not asked of the users, or the functionalities were not analyzed with rigor. Ask the users WHY a functionality needs to be a certain way, rather than “how exactly do you what this this screen to look?” If you are not asking WHY for every requirement, you may end up building something that may not solve the core business problem.
- Mock it up and Get Feedback: After understanding the gap between the problem and available solutions, the team works collaboratively to brainstorm solutions and sketch ideas. We have a talented group of user interface developers that can transform our innovative ideas into fully-clickable mock-ups. It is so much easier getting feedback on things that people can see and touch. This leads to a deeper level of discussion that reaches understanding in hours rather than months, shortening the development cycle. After just a few discussions, we can converge on a solution that satisfies the requirements of all parties.
- Make it Intuitive: Not all aspects of what we develop are visual. For example, if it is a process in the background of the user interface, we show simple design flows with imagery or icons; this makes it easier to digest than complex descriptions or detailed charts. If you can’t explain your product behavior to the user community without resorting to very complex spreadsheets or multi-page diagrams, it just isn’t simple enough – it is time to go back to the drawing board. If you can’t contain the product in your head, how do you expect other people coming in cold to contain it in their heads?
“Things should be as simple as possible, but no simpler.” – Albert Einstein, Physicist
Technology helps solve business problems. The best technology is simple and intuitive but still delivers the functionality expected. Some developers or product managers simplify projects by leaving out essential complex functionality. You can’t gloss over complexity. You must digest the complexity no matter how much of your time it takes, and give people something as simple as possible but still deliver ALL the functionalities required.