Bad Habits at Creating Products: Building the Entire Product

I’m part of the innovation/product development area at a software engineering company. Our main goal is creating other revenue streams for the company from SaaS products. We’ve been at it for a couple of years, but we still have some challenges to overcome, particularly in the form of mindsets and habits we need to change, in order to launch more successful products to the market.

I noticed that the following rather unproductive habits are very common among startups, so I decided to highlight the most relevant ones and the ways we are trying to tackle them.

  1. Focusing on Ideas Instead of Problems
  2. Wanting to be Generalists Instead of Aiming for a Niche
  3. Building the Entire Product Instead of Using Code-Free MVPs

This is final post of the series and will revolve around the third habit.

Building the Entire Product Instead of Using Code-Free MVPs

A big challenge for most startups and for us, being a software development company, is abstaining from coding in the early stages of the product development process.

Many developers who’ve identified a problem or come up with an idea tend to start by doing what they know best: coding. Why is this a problem? Developers take pride in their coding skills and most of them don’t feel that comfortable showing an unfinished product to their peers, let alone their users. Therefore, they start coding as soon as they come up with the product idea and expose it once it’s a working beta prototype.

After investing months on a product you tend to get emotionally attached to it and receiving criticism gets harder. So, validating for the first time with a robust prototype gets tricky in the sense that owners are not as prone to dispose of their prototypes and start over once the response from users is negative. Instead, they try to adapt the feedback they get from users into their monster product, which in turn ends up being even more complex than before.

“If you’re not embarrassed by the first version of your product, you’ve launched too late” — Reid Hoffman, founder of LinkedIn.

To build successful products we need to a change of philosophy, as Jake Knapp, author of Sprint puts it “from perfect to just enough, from long-term quality to temporary simulation”. Yes this can involve some coding, but only if it does not slow down the learning process.

I love this quote by Jake Knapp because it forces us to realize that prototypes need to be built and put to test as fast as possible.

“Instead of taking weeks, months or even years building that solution, you’re going to fake it. In one day you’ll make a prototype that appears real.”

How can this be done? First, by getting into the Prototype Mindset:

  1. You can prototype anything
  2. Prototypes are disposable
  • Don’t prototype anything you’re not willing to throw away

3. Build enough to learn, but no more

  • You don’t need a fully functional product

4. The prototype must appear real

  • In Sprint, Jake Knapp mentions that they use Keynote and InVision at GV to make their prototypes.

Second, by learning about prototyping alternatives that require less time and effort than coding the whole thing.

  1. Landing pages

There are plenty of sites that enable you to create great landing pages without having to write a single line of code, such as Launchrock, unbounce and KickoffLabs. By adding some mockups an explanation of the product, how it works and a signup button you can measure the response of your target audience on the early stages of your product idea and gather valuable feedback to improve it.

2. Hollow MVPs

A hollow product is one that looks and feels like a full product on its surface, but it’s being faked on the back end.

Suppose you’re building a user testing platform for new features. Instead of building everything, you could just build the screen where the user uploads her mockups and picks her desired audience. Once she submits the mockups, you can make the process seem automated by looking for testers and manually creating the user’s report. This way, if the report is valuable to the user, you can plan on building the actual thing. If not, you can pivot without having wasted a lot of time coding and you avoid rework.

There are many other ways to test product ideas fast, but regardless of the method one thing is certain: you need to get out of the building and talk to potential users. Building an app for Scrum Masters? Find a Scrum community and talk to them before you start building.

The good thing is that you can get out of the building without actually leaving the building. There’s plenty of communities online you can reach out to for feedback. Here are a few ideas:

Helping product teams realize they can test their ideas before building them is key in order to obtain validated learning fast and launching successful products to the market.

How We’re Tackling it

Changing this mindset takes time and can only be done by training teams in Rapid Paper Prototyping and by guiding them in the process of validating their ideas.

We’ve successfully created a code-less MVP for our most recently launched product, Agile Retrospectives for Confluence. We started by identifying the problems teams had while running retrospectives and identifying the need for a tool in Confluence to do so. The first thing we did was analyze how most teams run retrospectives and from there we started planning out features. Instead of building them our kick-ass UX designer created high fidelity mocks on InVision and we ran usability tests with them. We were able to refine our ideas and see which features were truly valuable to people running retros.

InVision mockup of Agile Retrospectives for Confluence

The challenge is now applying this lean approach to all product ideas at Nearsoft to help teams validate them faster. To do this we’re working on a Product Development Process consisting of 4 stages: Discovery, Ideation, Implementation and Validation. The idea is to guide teams through each stage and its activities so they can launch validated products quickly.


These are the top unproductive habits we need to change to launch successful products. Hopefully our experience will be useful for other teams going through the same ordeal.

This reading list can further guide you on tackling these habits:

Have you encountered other habits that slow down or prevent teams from launching successful products?