blog Product Management

Product Development Process (from Quora question)

I’m often contacted to detail our product development process with other departments in my company. I am the CTO and the only developer within my company. I understand oversight, however, I believe there is a better way to go about this. What do I do?

A few things strike me as odd.

  • You are the CTO. Which means you are responsible for strategy and the highest level of technology planning and execution across the whole company.
  • You are the only developer. Which means you are tasked with tactical day-to-day execution of someone else’s orders/asks/instructions based on someone else (again) collecting and prioritizing requirements from different departments.
  • Your company has other departments – this assumes you are not a one-man-show and at least have other people working towards company’s objectives.
  • Your communication with other departments is not transparent enough, so they end up asking about processes.
  • It is not clear if any processes exist
  • It is not clear if there are any other developers involved as consultants, freelancers or as an external vendor organization.
  • It is not clear what these departments are, but based on my previous experience I am going to assume that Sales and Marketing are among them.

Assuming you actually have those processes and is able to talk about them.

First and foremost – why is it important to be transparent about the processes of product development. Regardless of software developers, who may prefer to live in an agile world, most other organizations live in a waterfall. They often have to wait for a certain phase in product development to begin working on collateral, prepare PR statements, announcements, ads, one-pagers and whatever else helps to promote and advertise the product (even if it’s internal). You can’t just throw product at them and say “here, go sell it”. Additionally, early stage feedback (usually collected by Sales and Marketing orgs) is crucial to the product’s success.

Communicating “where we’re at” and “next steps” and “it will be ready by XX date” is paramount to the success of the product, not just individual departments.

Second – “Next Steps”. Marketing, Sales, and Support (at least these three) must know and plan ahead for the product launch as well as any upcoming releases. Marketing needs to be able to create materials promoting and educating customers on your product and changes to it. Sales must be able to talk coherently about benefits, new features and, in some cases, be able to say something like “this feature is on our product roadmap, it’s scheduled to be released in Q4 of 2018”. This alone may be a difference between securing a customer or losing it to competition. Sometimes customers may be tempted to convert to competition, announcing your plans may actually provide them with internal reasoning to stay with your company.

As you can see, at this point there are much larger reasons to be transparent about development processes than oversight. Other departments, most likely, want to look into your processes because it helps them do their job, not because they feel like they need to tell you how to do yours.

Now, being a CTO and the only developer can mean one of two things:

your company is very small – early stage startup small. This usually means that you really don’t have departments yet – you have Jake who does marketing, web design and creative copywriting and Jill who handles all sales calls, follow-ups, arrange your CEO’s calendar and probably does some accounting too. In this case – just go over to them and talk.
your company is not very small and you outsource most of your development, making you the only developer within the company’s ranks, but not the only developer for the product/company. In this case, I may suggest looking at your priorities – do you want to write code or do you want to strategically manage technology for your company or product. If you want to write code – drop the title, focus on engineering aspects and let someone else lead. If you want to be the CTO – stop focusing on a tactical day to day tasks and focus on a big picture. I am not saying you can’t do both. I am saying if you continue doing both you will not be effective. It’s not just my opinion – check, if you will, Peter Drucker’s “The Effective Executive”. By doing both you’re diluting your time that should be spent somewhere else. Time management is one of the most important aspects of being an effective software engineer, but it’s absolutely positively the most valuable asset of an executive.

Bottom line – the ask for more transparency comes from other people who rely on you to deliver things, but that can never be sure what is being delivered, when and how. Oversight is the last reason on that list.


The Only Good Time For Optimization Was Yesterday

As a part of my responsibilities in managing things the word “optimization” doesn’t come up often enough. Not a single business is against growth. Almost every one of them has a fear of optimization. Optimization is disrupting, hard and rarely bring shiny new stuff into the house. Instead, it’s like refitting your Ford Pinto with 2012 Mustang’s engine. Still looks like Pinto, only doesn’t go BOOM anymore.

The word itself has got a bit of a bad rap to it, usually meaning drastic cost cutting measures, layoffs and other ugly things introduced by “effective managers” (or “effing managers” for short). The real optimization rarely has that ugliness to it- going back to the previous example it is like putting s new engine in an older car.

The truth is, of course, that optimization is necessary – what got you to your current level isn’t necessary good enough to get you to the next. You realize that you hit the ceiling, reached the threshold, filled to the capacity. You need to break out of the box, shift the paradigm or in other words – you’re gonna need a bigger boat.

That’s where the real optimization come in. And – it’s late to the party. Optimizing when you already are stranded, short on time and resources is like trying to load up on already overloaded truck hoping that once you make that one critical trip everything is going to get easier. History and experience shows that it won’t. That’s why you need to start optimizing before the need arises. If you think you need it today – you’re late already.

A lot of companies decide to start small – it is a matter of startup capital, of course. But when planning their growth they often put unrealistic goals in order to account for it, while in the real life by the time they reach the threshold they optimize and they do it in the time that is least suitable for it. Instead of concentrating on growing the business they go back to the drawing board.

Your optimization should start before you need it. Ideally, you can start a process of ongoing optimization, an iterative process that runs in parallel with everything you do. As an example – every month you review your sales revisit your processes (at least some of them) and see how they can be improved to free up resources – get more sales, serve more customers, ship product earlier.

It should start yesterday.