Building a successful Proof of Value – Part 1

Lessons from a medical devices startup that scammed Silicon Valley In the book ‘Bad Blood:: Secrecy and Lies in a Silicon Valley Startup’[1], John Carreyrou talks about the rise and fall of a start-up Medical device company called Theranos which promised a simpler and cheaper alternative to full range of blood tests. Theranos claimed that its device would allow patients to test their blood at home with finger pricks (as opposed to venous blood draws) and send the test results to the doctors digitally. It was all smoke and mirrors until Theranos was exposed for making false claims about a product that was nothing close to being workable. The CEO of Theranos was eventually indicted of conspiracy and wire fraud². 2019 is touted as the year that will see the identification of use cases gain strategic advantage from emerging technologies like Block Chain and Virtual Reality. The first logical step in the process would be to identify use case and build limited implementations that can establish ROI – essentially, Proof of Concepts that can demonstrate value or Proof of Values (PoV). What can IT organizations learn from the Theranos story when it comes to building such Proof of Values? First Line of Defense: The first line of defense for Theranos were its board of directors. Unfortunately, no one on the board knew the subject well enough to check the claims made by the CEO.  Some checks and balances in early PoV stages helps ensure that the outcome reflects the organization interests. Here are some things to keep in mind:

• Based on the technology selected, ensure you have the right technical skill set – if you don’t have the right skill on the team, try to find someone who is enthusiastic about picking up a new technology.
• Identifying the right business case is critical for the success of a PoV – Listen to the right stakeholders and find out what use cases are valuable to the organization.
• Use the technical expertise to establish which use cases have the least technical complexity when it comes to implementation. Use case that are most valuable to business and least difficult to implement will your team’s quick wins.
• Provide regular feedback to the team if it needs a course correction but at the same time give them the recognition they deserve in the absence of structured incentive mechanisms – Remember, praise in public and criticize in private!

Listen to people in the trenches: There are several accounts in the book where employees have complained about the feasibility of the technology and quality control to deliver a full range of blood results based on a finger prick. Sometimes you may be faced with a situation where you got a developer interested in building a POV and they are willing to spend time beyond their regular work hours as you have convinced them of a win-win situation. Kudos to you, now you have their attention! But what’s important to sustain the implementation part is to ensure that you pay close attention to your team’s inputs during the course of development – one way to achieve this is through scrum ceremonies. Yes, that’s right! Just like any other agile project, PoVs can benefit from have the sprint planning, product backlog, retros, product demonstrations and collaborative tools. Developers who are working on other projects in the same client organization may have insights into what has worked well technically; Analysts / Scrum Masters will know what features the customers really want. Don’t overpromise and then cut corners: ‘Under promise and Overdeliver’ is the mantra of service strategy. That’s exactly what Theranos did not do. Instead, it made a promise to deliver a revolutionary device but when it came to delivery, it fell way short on its promises. When it comes to PoVs, while its okay to inform the customers of what’s in works, be wary about what you promise. When it comes to unproven technology, there is a high risk of running into roadblocks. This means that there is a high probability that you may not have a timeline on when and what you can demonstrate to the stakeholders. Keep in mind, that you would want to focus on building thin vertical slices that cuts across all layers – Backend, Integration, and UI. Make sure you have a workable solution that is a limited example but fully integrated. [1] https://www.nytimes.com/2018/05/21/books/review/bad-blood-john-carreyrou.html ²https://www.nytimes.com/2018/06/18/business/dealbook/holmes-theranos-fraud-case.html Image source