Posts Tagged "Product Management"


As our team gets closer to launching our latest start-up, I wish to pass on a piece of advice that has been a tough lesson for me to learn. Working on the business side of the shop, I have fought against automated tests for a while.  That all changed recently. My epiphany came after dealing with a few problems, doing some research and receiving sage advice from multiple people while working on Printchomp. The conclusion I reached was that automated tests save developers time and let you deliver more. This was a painful admission, but a correct one. Let me explain further as to how I came to this realization: 1.     Time it takes to do QA (Quality Assurance) without automated tests – I have been in multiple start-ups where automated tests didn’t exist, and let me just say the QA overhead was astronomical. Every time a new feature was rolled out we would have to check the code in multiple browsers in painstaking detail to see if a user could still make it through the checkout process. Due to the fact that basic testing flows weren’t in place, we would waste countless hours every time a new change or feature was introduced. 2.     It keeps the locus of control of the QA process closer to developers – I have advocated for a long time that there needs to be closer ownership of code by developers themselves. I have seen many instances where code was checked carelessly, and then tossed over the fence for the QA and business folks to find and fix the errors. With automated testing, developers can run more localized testing and make quick fixes that don’t involve monopolizing QA.  Running unit tests ahead of code check-ins are an invaluable step to save headaches later and reduce stress between stakeholders. 3.     You build faster – While it seems counter-intuitive, building tests saves you time in the long run. The knee jerk reaction is to spend your time building new features. I have had this reaction many times, but I realized I needed to change it. The best way, I think, is to think of your product as the Starship Enterprise. Scotty, an engineer, can only check so many things at once.  An automated test multiplies the ability of Scotty to diagnose and test multiple things. As Captain Kirk, your goal is to keep the Enterprise going forward. Something as simple as automated testing can keep you going at light-speed. One of the biggest time sinks in development is finding the problem. With proper tests in place you can isolate and figure out where the issue is. 4.     Ramps up training of new developers – With automated tests in place, it is easier for new developers coming into the system to understand code that they didn’t write. There is no one, probably not even your CTO, that...

Read More

30 days out from launch I was reflecting on the top things I need to do to help make my company as successful as possible. Here were the top 5 things 1. MVP, MVP, MVP – This isn’t the time to get fancy with all the bells and whistles. You can always build them later. This is about making sure your system works. The question here should be “Is the baseline user experience working?”. I have been tempted to ask for this, that and the other. At the end of the day, the system needs to work in its purest form. 2. You are the Quality Assurance and the product manager – Testing is never a fun activity, but guess what? It is your responsibility to go out and test every freaking button, every square pixel of your user experience. IT IS YOUR RESPONSIBILITY TO FIND ALL OF THE BUGS! 3. Focus and inspire your team – As the fearless leader of your team, it is your job to keep everyone pumped and excited and firing on all cylinders. It is easy for everyone to get distracted with background noise. Whether it be showing up with pizza while everyone works into the night, or passing on an encouraging word to someone who is really rocking it, it is your job to help everyone stay on their A game. 4. Prime the pump – Work with your perspective partners and customers ahead of time. If you haven’t done this yet, this is the time you want to start speaking to them. You want to hit the starting line with a running start not with a dead stop. This will rapidly help and ensure you will get moving faster. 5. Ask for help – You are only one person. Although you may be running yourself ragged to be all things to all people internally and externally, you need to not be afraid of asking for help. Friends, family or colleagues (assuming that you haven’t pissed them off) are generally more than willing to help you. Make sure you keep track and get ready to thank those people when you achieve what you set out to do. More times than not, people can forget or not be appreciative to all the people that helped them along the...

Read More
You are building too slowly

You are building too slowly


Posted By on Oct 25, 2011

When I was a child I played with Lego. If I was at home, I had the leisure of playing with my own Lego, and I could take my time and build an elaborate creation. I would go to meticulous detail in building ships, castles or other buildings. I realized there was a certain serenity to playing my own sandbox at my own pace. When I went to kindergarten, I noticed they had a large box of Lego. When I went to play with it for the first time, I got upset that there were other kids taking blocks I wanted to use. I wasn’t afforded the luxury of taking my time, because if I did, I wouldn’t have the pieces needed to complete what I wanted to build. This is a simple parable but it made me realize that I was building too slowly, and not afforded infinite timelines. I thought back to this during Democamp, where a company named VidYard built an impressive application in 16 weeks, got funded and are now on the upswing. This example made me realize that if you think you are building something quickly, you probably aren’t and will pay the price for it. The level of competition in the software/web application space has only gotten more intense. The ability of a focused and dedicated team to build something quickly is needed more than ever. What I have come to realize is that zealotry of innovation is powerful. People with a taste for both innovation and building something are hard to stop. Last week, due to this epiphany, I decided to try to tackle something in one week that would normally take me multiple weeks. I refocused, got team buy-in and went to work. This didn’t come without bumps – the time I would normally take to think out every nuance was not there. I stayed up late and built and tweaked until it was ready. I would argue that a perfect plan with nothing built takes a backseat to something that works that perhaps isn’t perfect. It may sound cliché, but a good plan today is truly better than a great plan later. At the end of the week, I lost a lot of sleep and built out something cool. I didn’t quite hit my timeline, but when I looked back at the week, I saw that my team and I had built a lot and learned a few lessons. So you want to build something quickly? How do you do it? Set an unrealistic timeline. How better to start this project? Ask yourself how long it would normally take on...

Read More

1.     Minimal Viable Product thinking can be a trap – there has recently been a huge movement toward creating a “minimum viable product” and then going out to market as quickly as possible. I would argue it is important to temper this trend. This has turned into a tendency to quickly roll out half-baked functionality because developers believe they are following the MVP mantra.  Well thought out features that deliver value, even if they take a bit longer to come to market, will (in my opinion) deliver more ultimate value to the product and to the user experience. I am all for iterating something early on once it is in the hands of the customer, but I would argue that some companies have misconstrued this and roll out an untested, half written piece of functionality 2.       Keep an eye on what really matters – Many good product managers fight with this all the time. How many times do people from different lines of business ask questions like “wouldn’t it be cool if it could do this?”. When I really boil it down, there are only 3 reasons why you should build any given feature in an early-stage start-up. Here they are: It will help make money – If you are a start-up working towards break-even, then this needs to be ever present in every decision you make. If it won’t help move the needle and get you closer to profitability, you may want to reconsider it. I come from a school of thought in which you want straightforward business models with a straightforward path to cash. There are few out there with unlimited runways and you always need to be concerned with this in your approach. It will improve the user experience – User experience has become such a core function to any product manager. Is this easy to use? Do people get pissed off when they have to use key features on the site? Will it cause people to abandon your site?  UX can be a core competency and key differentiator. Always focus on this! Even if it is as simple as a nicely done pop-up or a cleanly designed button, it all matters when it comes to UX. It will improve efficiency and scalability – Will this feature allow you to do more with less, does it allow you to hold off hiring more people to do the same function, or does it make the people you have more effective? You should always consider this to stay lean and mean as possible 3.       Create a vision for the product – it is important to not limp forward from...

Read More