The information below is learned from releasing 20 something products as agency and now a product company. I understand that you may have a different experience. This is just one set of constraints that in this particular combination have been found to work well. There are many ways of doing things.

When we want to build a new product, we usually think of a “promise” we want to make the user.

This is usually something that we believe wows them if done right.

This promise is usually dependent on multiple experiments working out favorably. …

I’ve written another super fucking obvious article because I had nothing to do tonight but fuck it, I wrote it anyways.

Witten communication assumes that the person writing can articulate themselves.

It assumes that they have put aside sufficient cognitive resources to be able to combine the right words and think about how they will be received.

It assumes that the communicator is not afraid of being misunderstood.

It assumes so many things that are so many times not true.

The most critical things you want to get out your team are often ones that are hard to articulate. …

I almost didn’t publish this because it seemed so obvious after I finished writing it.

I guess what’s not so obvious is knowing which kind of organization you are when you join or start a company. I’m speaking from experience. Freshout operates two different companies today. One is product driven and the other is primarily sales driven.

I’ve yet to meet a person that can perform well in both types of companies.

I say that because it’s so hard to think that a group of people that would pour their heart and soul into making amazing products would be ok…

Placeit works as a professional App Demo Video Maker that allows you to highlight your app’s features and present it within an engaging storyline. However, with so many resources and tutorials out there, it seems like setting off for a DIY project is also a great idea. We put together a few examples in which people decided to create a demo video for their apps. …

When comparing the better tested / spec’d deploy vs the “screw it, just deploy”, many have found reasons to go for the latter.

We see a lot more buggy software out there as users as well. Why does so much buggy code get into production?

Maybe if we knew how expensive it was to ship buggy software, we’d do less of it?

Here are some not so obvious costs

• Opportunity cost of all the new customers we failed for
• Reactionary coding for putting up patches which produce horrible code
• The cost of panic in the entire company
• Wasted sales and marketing dollars driving to a broken product
• …

Consumers should generally go for the cheapest option when it comes to transport.

So do a non-profit/co-op version of Uber where the a very small % goes towards developing the technology and the rest goes right to the drivers with lots of transparency.

They could achieve lower prices for the consumers and the consumer also knows that the majority of their money is going to the driver, not Uber.

Seems like the drivers don’t really realize how much power they could have.

If the drivers get a bigger cut and it’s cheaper for the consumer, I don’t see how it couldn’t work.

I’ve thought long and hard about the right size of our company. I thought maybe I would walk you through why I’ve settled with this guiding idea:

Never compromise productivity & sustainability for the sake of feeling bigger.

Productivity

Freshout was 35 people about a year ago. It’s currently 25 people.

It does the same revenue that it did with 40 people a year ago, with 7 people today. The rest of our engineering team is working on new ideas.

That model has worked well for us. I have the numbers to prove it.

Whenever we feel like we’re not efficient…

in my experience, the biggest difference in an engineer isn’t their technical level.

it’s whether they have an idea of how their work fits into the product’s goal and what they do to inch the entire ship towards it.