Learnings on Opening a Lab

Posted by | Genomics, Startups | No Comments

It’s been a long time since I’ve written anything here. However, I have a good excuse! We’ve been busy opening a next generation sequencing lab!

Last year, by Dad and I were looking heavily at the space. It’s been a long time dream of his to build out a genome sequencing facility and it’s been a long time dream for me to once again blend software and life sciences (dabbled with this on my first company). Through a series of fortunate events, we had the opportunity to pull the trigger in September this year so we founded The Sequencing Center.

Since then, we’ve been working hard on the website, building out our marketing and content strategy, finding lab space, and so much more. My sister came on board to help out with everything as well, from social to account management. It’s been an all hands on deck situation. Now, we’re bootstrapping this and funding this from our day jobs, we haven’t quit the primary jobs so it’s double duty 7 days a week.

Just recently in March we found our new lab space. It’s a 1,400 sqft former surgery facility that met all the specs. A little old in age and a bit dirty but nothing a bit of TLC couldn’t solve. We signed in the middle of March and have been purchasing equipment since then. Here’s a list of just random shit that we learned throughout the process.

Getting used equipment takes forever. Seriously. The vendors in this space take forever to get anything done. Emails are usually responded within 24-48 hours, they’re highly unhelpful, and getting the equipment through QC often takes weeks. If you’re building out a similar lab, make sure that you have about 3 months of capital allocated just for the lease for while you’re purchasing equipment.

The price you see is never the final price. While this is pretty much true for most purchases, it’s especially true in this field. The vendors we worked with would provide insanely high quotes that we would haggle on heavily. As an example, one vendor quoted us $20,000 for a device which was about $6,000 more than another. However, they also had another piece of equipment we needed that the other vendor didn’t so we proposed to purchase the other piece of equipment at full price if we could get the $20k unit for $14k (a $6,000 discount). After adding a bit of added pressure to close the deal, they agreed. Everything is negotiable and if you’re a small startup on a budget, fight for the discounts.

The laws and regulations are extremely vague. Our lab is technically BSL2 rated which means we can handle a variety of sensitive organism. These aren’t likely to kill you but you have to have a BSL2 lab to handle them. Here’s the kicker: BSL2 labs don’t actually have a certification. This sent us down a rabbit hole because we assumed there was something we needed to prove that we could handle these organisms. However, after calling the EPA, CDC, local health inspector, and reviewing the 438 page document from the CDC on biosafety labs, we couldn’t find anything. Then, after talking with an equipment certifier to certify our biosafety cabinet, they said that only BSL3/4 have hard requirements. BSL1/2 have more “guidelines” than anything – an area of grey operation. As long as you had the proper certified equipment, manuals, processes, etc., then you should be fine.

Electric outlets. Make sure that you know the amp and volt limits of your outlets. Then, make sure that when you buy big equipment (such as a -80 freezer) that they map to your outlet specifications.

Have all refurbished equipment go through quality control. Make sure that in each of the invoices that you sign with resellers/refurbished vendors that they include the quality control inspection. Often times this just means turning the machine on and making sure it has some basic operations (centrifuge spins, freezer holds temperature, etc.). This is really more of a small insurance policy for you than anything else and will save you headaches.

Do a full run through the lab before accepting clients. This seems like a no brainer and fortunately it’s not something we’ve messed up on (yet!). However, this is extremely important because if you’ve accepted clients before the lab has completed a full run through and one of your equipment pieces fails, it could take weeks or months to fix. This will provide you with some pissed off customers and a hurt reputation.

We’re on the cusp of opening up our lab after a few months of painfully getting all of our equipment. We have 2 more major devices that we need and then we’ll be good to go. It’s been a journey so far and it’s only just starting. Should be fun!

The Balance Between Quality & Speed in Product Development

Posted by | Enterprise Software, Startups, Technology | No Comments

I’m going to make some controversial statements in this post regarding product management. If you’re currently a product manager, I’m sure you’ve been peppered with the “do this! don’t do this! you’re a bad PM if you do this! 10x PM’s do this!” rhetoric. Honesty, it’s exhausting. Earlier in my career, I read a ton of books on how to be an effective product manager. What stuck out to me is that these books often pushed opposite agendas – sometimes even within the same book.

Having gone through some of my product management career thus far, I’ve realized that there is no silver bullet to doing a good job. In fact, it largely depends on where you’re at in the lifecycle of your company, the industry, the team you’re working on, etc. These books often write about a set of criteria PM’s must meet. They pain the picture of a panacea outcome if you do these 10 things. That’s never the case.

What I learned early on (and quickly) is that there is a very hard balance between delivering high quality products and delivering them in a very rapid format. These aren’t mutually exclusive but they are very hard to balance. Sometimes they shouldn’t be.

For example, let’s say you’re losing a ton of business by lacking a major feature set. The company has put it off for too long and it’s now a top priority in order to help sales to stop losing in competitive deals. To create a feature parity product would take you a minimum of 9 months. Looking backwards, you know that you’ve lost $900k in the last 9 months to competitors because you lack this feature, so it’s safe to assume that over the course of this entire development of 18 months, you’ll lose $1.8M.

Do you build as fast as possible and ship something “good enough”? Do you go for a high quality product and release later?

Personally, I’d opt to release something that is barely good enough. Something that is almost embarrassing but paints the vision, dream, and demonstrates that we can accomplish the basics of what our competitor can do, refocusing the sale back onto features that you crush competitors on.

On the other hand, let’s say that you’re trying to leap frog the competition. Time is on your side and the feature you’re developing is very complex with a high barrier to entry from a user experience perspective. You know that if you ship early, its going to have little to no adoption which will make iterative testing and development challenging since you could be stuck building in the dark.

Do you build as fast as possible and ship something “good enough”? Do you go for a high quality product and release later?

In this scenario, I’d say build a high quality product with lots of UX/UI iterative testing, prototypes, etc. before you commit to engineering on it. This is going to take a lot longer but you know that by doing this, it’s going to make the adoption a bit easier. Plus, you’re confident you have time on your side since you’re blazing a new path through a different aspect of the market.

My opinion is this: product management is a case by case job description. There is no silver bullet method to building great products because every company is in a different place. A super fast, agile, and “release often” approach may not be appropriate for monolithic, highly audited and complex industries. A PM must understand the vertical and adjust their style to match the most effective form of delivering product in that organization.

This isn’t to say that the paradigm can’t change over time. Often times, it’s the product department helping create ways to be more efficient and deliver products in different ways. However, these things don’t happen over night and require a flexible product management style.

As the title of this post suggests, it’s a constant battle between delivering very high quality products and delivering products very fast to the market. They’re not mutually exclusive by any means, but rarely (in the real world) is the environment setup to enable both to happen.

New York, Paris, London – A Software Development Dilemma

Posted by | Enterprise Software, Technology | No Comments

New York is a well thought out, grid based, highly planned city from the ground up from the beginning.

Paris is a complex city with many organic roads that were built long ago but during the Napoleon era, a few large boulevards were built in order to increase the efficiency and connectedness of the city. A hybrid of planning and organic growth.

London is an organically developed city with curving roads, complex subway systems, and tons of legacy but is still a highly functional city.

In all three scenarios, each city is massive, efficient, has high production, and gets the job done. They were all planned in different ways but achieved the same outcome. New York wanted to be very structured, Paris wanted a hybrid, London opted for an organic route. No one city has it right and each have their own charms, cultures, efficiencies, and issues.

In enterprise software development, we have very similar issues. Enterprise software is uniquely hard to make sweeping changes due to scale, complexity, impact, and cost. In certain cases, adding just a single dimensions to a database can mean hundreds of thousands, possibly millions, of extra dollars accrued in storage costs due to operation scale – not to mention performance impact of query times. When a new product or feature needs to be introduced that has sweeping impact and ramifications for the rest of the organization, it’s often a good idea to take a step back to think about New York, Paris, and London.

Strategically, do you think it makes sense to rewrite 1/4 of the platform? Is there a work around? Should we just build something entirely new from scratch then migrate? Is there a middle ground where we can build a connection? Is that a long term solution or just a bandaid that will hurt us later? These are all questions that go back to the same macro level issues of city planning.

I think most companies start out with a basic plan but rapidly move into an organic model – much like London. The development goes in different directions, workarounds are instituted, compromises are made, it becomes more costly to engineer, but it still works. At some point, this scale can break down in which organizations move to the Paris model.

Moving to the Paris model means creating large boulevards that allow for certain efficiencies while allowing autonomy for organic growth to fit into those boulevards. Sometimes we even dig tunnels to find ways around the boulevards and organic streets, but at the end of the day we still provide connections to the main boulevards.

Then, at some point, the intersection of feature needs and tech debt forces organizations to consider building New York – a new paradigm that offers a foreseeable scalable solution and is well planned from the ground up. We build a basic version of New York and then start to port over all of the features. New York works for a while until we start to see flaws, in which we move back towards feature developments that model London and Paris: organic development.

Repeat a few times and you’ve got software development for the enterprises.

This isn’t necessarily a bad thing at all. Much of the worlds greatest software follows each of these patterns and have proven that no single model is “the best”. What has become very apparent to me is that it’s important to know which model you’re building after. It’s critically important because it highlights specific choices and sacrifices you’re willing to make.

Put simply: be aware of which what you’re doing.

Where I’ve seen these models fail the most is when organizations are not aware of the type of city they’re trying to build, making compromises or features that back them into incredibly costly situations. Now, this isn’t to say that you need to consider this for every feature. I personally think it pertains largely to more macro/strategic development (ie. user permissions, data portability, etc.).

Obviously we will make mistakes and sometimes choose to bulldoze the wrong areas in way of building our boulevards, but the hope is that by being more conscious about these decisions it will help shed light on the long term impacts and make decision making easier.