This blog is based on my participation in a panel during the Denver Startup week on 10/1 at Spiredigital.

Thank to Nick Coppolo for putting the questionnaire together.

What’s your view of product development and how does that guide what you do each day?
I could give the PMBOK definition, but, no,,,, for me Product Development is the art and process of marrying customer/business needs with technology solutions.

In my experience I’ve seen 3 challenges with this :

  • Customer needs are different from what they tell you they need.
  • Sometimes customers do not know what they need and requiere an expert advice (as Henry Ford said “… If I had asked people what they wanted, they would have said faster horses…”.
  • (We) Technologists like to build cool Shi*, that may not have anything to do with business needs or could include a lot of gold-plating.

To avoid all of this I usually recommend a lean development approach, short iterations and a lot of prototype development (when possible) – allow you customers to experience often and provide feedback.

What were some initial challenges you face in receiving approval or proving a market fit for your product, prior to beginning development?
This varies from project to project but everything usually boils to $$$, the easiest path to receive approval is to compare investment with ROI.

Did you often have to pivot throughout the ideation and development process, and why? Was it for the better or worse?
Pivoting throughout ideation and development is a key part of agile development, however I like to have a clear picture of the end result before starting. The worst thing we can do to a development team is to switch gears in the middle of a project and start building something completely different. On the other hand, fine tuning is expected and should be welcome.

What does your product development team look like?
This also varies from project to project. Ideally we have a project manager, a BA, a product manager (the liaison between the business and the tech team), a testing team and a development team. If the project is developed using a partner or an agency, we usually try to match up their resources with few internal resources (which I name “champions”). I.e. have an in-house product manager working with their product manager and BA, an in-house developer working with their development team, etc – this practice helps to keep key knowledge in house and drive the use best practices.

What’s your view on outsourcing or using outside resources to develop your product?
Related to this question I distinguish two types of outsourcing: by project and staff augmentation. The earlier implies that the vendor/partner/agency provides a full project team and sometimes own processes (that I rather complement with internal resources as I said before), the later means just an addition of developers to augment delivery.
In both scenarios it is just a matter of finding a partner that clicks with the company culture and the internal team. Sometimes that click will be driven by really subjective things (I “like” their developers), sometimes will be driven by objective things (we can only work with local/on-site resources) and sometimes a combination of both – the key is to find what works for your team and company and find “partners” not simple “vendors“.

What are the keys to shipping product to market quickly and successfully?
The main challenge is to go from 0 to 1 and come with that MVP. Projects get delayed a day at a time and frameworks like scrum help to mitigate or prevent this.

What advice would you give people in the beginning stages of developing or ideating their product?

  • Have a clear vision for your “forest” and start planting “tree by tree”.
  • Spend good time in ideation and architecture, but do not over spend. Build a bazaar not a cathedral.
  • Adopt agile methodologies.
  • Build you architecture to scale (do not underestimate your possible success), this applies to both hardware and software.
  • Decouple your architecture as much as possible, this will allow you to distribute and parallelize work.
  • Create prototypes and get user feedback soon, do not ideate in a vacuum.