How We Supercharge Product Development at Philosophie

Co-authored by Chris Butler

Russell is a developer working on expanding his product strategy capabilities; Chris is a senior product strategist (and ex-engineer) looking to keep his development skills up to date with the latest technologies. We’ve both been thinking a lot about how development and product interact on a Balanced Team and within a user-centered development process.

We put together this simple list of factors to focus on that we think facilitate great collaboration on projects. We’ve found that being sensitive to them can not only improve the overall team dynamic, but can lead to a better, more thoughtful product.

1. Conversations

Russell: Though it seems like something that should go without saying (pun intended?), keeping the lines of communication open between Product and Development is crucial to the overall workflow of the project. This is oftentimes difficult to enforce: in a typical agile environment, information may move through a number of different channels (e.g. Trello, Pivotal, email). This is why we prefer to use Slack for project-related communication as much as possible, keeping everyone in the loop on all communications, regardless of their specialization. For each external service we use (e.g. Trello, Github, Codeship, etc.), we set up integrations for the project Slack channel to increase everyone’s visibility into the process. Even though Chris doesn’t necessarily care about each pull request that I open, it allows him to see a high-level overview of what the engineers are working on and what they are discussing.

Chris: Project conversations serve two crucial purposes: to increase alignment and to make decisions. In many organizations, these conversations happen in big, occasional meetings that typically involve reviewing specifications, reporting statuses, or discussing schedules. Because these meetings are infrequent, making decisions and building consensus are much more difficult. Everyone can come away feeling out of touch.

At Philosophie, we focus on aligning and deciding as frequently as possible. The key to this is through conversations that happen throughout the day. Slack is a great way to have a flow of conversations, but there is really something to be said for adding more personal context. The higher the fidelity of the conversation, the faster the alignment and decision making can be between people.

When discussing communication, turnaround time on questions is something product can help reduce. What I look for in great product people is the ability to help move things forward quickly and not be a blocker for decisions, thus closing the loop faster. The product team should strive to remove as much ‘waiting’ time for engineers as possible.

2. Alternative Approaches

Russell: A big part of a developer’s responsibility in product development is to be able to articulate clearly what can and cannot be done from an engineering point of view. Whenever an idea has to be tabled or put into the backlog, I always make a habit to propose alternative approaches so that the product owner and/or project manager can make an informed decision on how to budget time going forward. Maybe it’s worth it to allocate some resources to a less-than-perfect solution for user testing, so we can validate the feature and see if it’s worth it to invest time in building a bespoke solution.

Chris: Engineering makes a lot of decisions that impact product intimately. These tradeoffs are very important for everyone to understand and not be surprised by them later on. Of course, engineering can’t predict all of the implications of their decisions when you are working on a highly iterative product. The goal is to make sure that as much is known about the possible solutions when a decision is made.

An option that is more commonly discussed in the lean startup community is to build a shell of a service to see if there is any interest at all. If there is interest, which features will be the most important to getting people to sign up? By building just enough you keep your options open for later features until you know more.

One option that I don’t hear discussed enough in iterative product decisions is faking it. While it isn’t in engineering’s nature to build something that doesn’t work on purpose, it is an option that should be considered. For example, building out a complex way to handle cheating in a new game isn’t necessary until you see how cheating takes place. Until you do, build just enough to track cheating and deal with it manually instead of an automated system to eliminate it.

3. Build vs. Buy

Russell: This is similar to the previous point. Essentially, when building a digital product, you decide whether or not to use existing solutions (“buying” — i.e. using third-party dependencies like gems, npm packages, services, vendors, etc) or writing your own solution from scratch (“building”). Because we at Philosophie focus on new product development and rapid iteration, we tend to leverage open-source frameworks and libraries often. However, in many circumstances this tradeoff becomes more complex. The best approach I’ve found is to let the product owner know what buy-able solutions are out there, what the pros and cons of each are, and how much time it would take to build bespoke versions of each, along with the challenges that would be faced in doing so.

Chris: I have personally found that what makes a particular project special is the glue that pulls known parts together, rather than rebuilding basics. Don’t be afraid to stand on the shoulders of giants. We already do when we choose an OS or a programming language.

The pushback from engineering is generally about dependency hell that can result from too many external integrations. The best thing that a product person can do when discussing these options with an engineer is make sure that the strategy of the project (or business) is well understood. As with most good strategies it is about saying ‘no’ to what doesn’t matter. If you say ‘yes’ to everything then you are not effectively focusing on what matters. This concept is at the heart of build vs. buy — build things that are core to the business strategy, buy things that aren’t.

4. Technical Debt

Russell: I’m trying to make it a habit of discussing technical debt with product owners before a project kickoff, as well as documenting technical debt at the end of each sprint (even if it’s just in the form of an email to the team). This way, the product team has documentation of the tradeoffs that engineering has been making throughout the process, empowering them to better decide when to pay down technical debt.

Chris: There are times when the team will need to take shortcuts to learn something quickly. There are very few times that taking on a little technical debt early on in the project is bad. As you learn you become better equipped to rebuild things right.

The same could be said for technical debt related to scaling up. For high-touch B2B services you will find problems as you grow from 1 to 2 customers, 2 to 5 customers, 5 to 20 customers, 20 to 100 customers, etc. When you are a consumer company it is usually when you are scaling your customer base by orders of magnitude. When it comes to scalability, it is best to not optimize prematurely. Doing anything to find these problems before they are ready to reveal themselves is not high-value work.

What is important is to understand that debt weighs down development before it is paid off. Understanding what debt you take on and regularly discussing it is what allows you to manage it effectively.

5. Prioritization

Russell: A common tendency for developers is to work on more ‘interesting’ tickets before less interesting ones. However, as part of a Balanced Team, we as developers should be working with the team to prioritize items that have the highest impact, rather than working on a feature that might be more fun to build but has a lower impact on the product (or at least the current sprint).

Chris: Product’s main job is to ensure that the team is always working on what is most important. Depending on the point the team is in the project this can change what is a priority.

Earlier in a project, the team should focus on building and testing whatever is most risky to the business model. This helps reduce the likelihood of building the wrong things. We should be learning as much as possible, as early as possible.

This is balanced against what is necessary to offer a ‘whole’ experience within the service or product. For example, registration is not something that is very complicated to understand or execute on, but it eventually needs to be done for a product.

6. Prototyping

Russell: Prototyping lets us take shortcuts to validate usability and desirability with the users before we invest a lot of time into programming. For instance, if we’re considering a feature that requires a lot of complex business logic, it might make sense to first create a prototype with the internal calculations faked or simplified. This way, you don’t waste time building a lot of business logic before you know the feature will end up in the final product.

Chris: To some degree, prototyping a feature means you are using technical debt to your advantage. Knowing that you will throw away a prototype after learning what you needed from it frees the team from thinking through edge cases, future uses, and performance issues.

It is up to the product person to facility the discussion of what prototypes actually need any engineering. It is always cheaper to build prototypes that involve less design or less engineering. Even a simple landing page can be done with a site creator or framework that helps test whether a feature list, messaging, etc. works for potential users.

Final Thoughts

Russell: I recommend involving everyone on the team in the technical discussions, at an appropriate level of detail. Having pull request notifications posted to Slack might be a good place to start. This will give everyone on the team better insight into how the development process is actually coming along, and can help them help you.

Chris: From a product point of view, I recommend making great team communication the top priority. The more often you communicate the more likely everyone will share the same mindset. A common mindset is the first step to a high performance team.