read

Recently, one of our clients was having a hard time determining how to position their product for a market they were going after. The founder felt that the product, an estimation tool for landscape architects, could also be used by other contractor companies like painters, general contractors, and other construction related industries. He didn't know whether to focus his product towards the niche or build with the other markets in mind.

In the early days of designing a product, one of the hardest things for founders to do is determing whether to narrow a product's focus to meet a specific niche within a market, or building the product with the flexibility to meet a broader market while initially targeting a smaller subset of that market.

Making this distinction is an incredibly important decision to make early on in a product's lifetime because it determines how each new feature is approached. At Sticksnleaves, we call this methodology-based products versus framework-based products.

What's the difference?

When you design products using a methodology, you focus on building the product to meet an optimal system or method for a particular user. The software is opinionated, in that if the user follows a similar work flow or process that matches the software, you're more likely to gain adoption with that market.

A great example of this type of software is Pivotal Tracker, a project management tool for software teams that subscribe to the agile method of software development. If you don't know what agile development is, you will likely be very confused about how to use it.

On the other hand, designing products using a framework means that the product has a loose structure by which you utilize features. The end users may have vastly different workflows or processes, but the software allows the user to create their own structure and workflow around how they use the tool.

A great example of this type of software is Asana, a project management tool built around teams. The software allows teams to organize a project and work through its parts in whatever way the team currently works. If you produce work using a very rigid workflow, it may be hard to adjust to Asana's loose structure.

Here are 8 things to consider when designing for one versus the other.

Framework:
1. Your market is broad Your target market is broad. You're not limited to a subset of the market, or a particular market at all. Large markets or products that span across markets mean plenty of room for customer growth.
2. You should still pick a niche early on Even though your product can be everything to everyone, you must fight the urge to sell to anyone that will buy. You have to pick a market and target your sales and marketing efforts or else your brand and your messaging will be inconsistent and ineffective.
3. Product development is harder With every new feature, you must think long and hard about whether that feature pigeon holes you into building too much structure that might alienate a subset of your users. Some alienation is expected, but you should always aim to build features that ~70% of your userbase will use if you utilize a framework.
4. You'll likely have to show the user some use-cases With a framework, users are less likely to immediately grasp how to leverage the product within their workflow. You have to do more education, demonstrating different ways to use the product. The great part about this is once you show them a few different ways, users tend to extend the software into other use-cases you hadn't thought of.

Methodology:
5. You can optimize intelligently With a methodology, you have a fairly defined workflow that all users subscribe to. Your goal then is to find the most optimal workflow to aid your user through that process.
6. You alienate your potential market The more you optimize for a particular workflow, the harder it is to attract and activate users that don't subscribe to that workflow.
7. Acquiring and activating users is simpler All of your effort is directed to a known type of user where the "time to wow" the user is decreased because the user likely understands how the product fits with their existing workflow.
8. It's easier to understand what to build It's likely that if you're using a methodology to build the product, you have a very good understanding of the basic workflow a user goes through to accomplish something. Thus, it's likely easier to build the product in flows to match.

As you think about the product in its early stages, take some time to consider your strategy and approach as it will have pros and cons to approaching the market you're going after!

Blog Logo

Sticksnleaves


Published

Image

Sticksnleaves

Thoughts on building great products

Back to Overview