Matthew Zammit的动态

Great conversations going on in this comment section! A couple of hours ago John Cutler wrote an insightful post which adds to this and clarifies some questions we've been raising. "things really get interesting when cranking out features *might* be the right thing to do (for some time, at least)." Thanks John Cutler for being generous with your ideas. Here's the post... ?? "In 2016, I wrote a post called?12 Signs You Are Working in a Feature Factory. The uncomfortable truth I did not cover in that post is that some businesses do just fine as feature factories (for some time, at least). This is especially common in situations where the solution space is fairly known, and there is a premium placed on "catching up" to legacy competitors while adding a new twist like mobile, cloud-based, new technology, new business models (SaaS, for example), better UX, etc. The big challenge in these situations is walking the tightrope" ... go through the rest of the post ?? https://www.dhirubhai.net/posts/johnpcutler_in-2016-i-wrote-a-post-called12-signs-you-activity-7090843852848197633-plEV

Matthew Zammit I have seen people who are emotionally attached to their idea tend to write a lot of code. Typically they say, 'Cut the crap, and put the software before the user first'. They have a big assumption that they understand the need. But the key is finding the real need of the customer which would lead you to the product market fit. Features should be seen as high-fidelity prototypes. There is a cost associated with writing features. If you can find ways to validate your hypotheses/assumptions without writing a single line of code or much less code, you are a genius. If you validate hypotheses/assumptions after investing thousands of hours, you may be investing a little too much, but again it depends on the situation, you should not feel bad about it.

I’ve been thinking about this a lot lately, Matthew Zammit. I’d say there is always room – and reason – for discovery if one lets go of the idea that there is one particular right way to do it. In the case of an early-stage startup, I’d assume, before the first line of code is written, the core idea behind the product has been refined and derisked to a proper degree. So you start with a basic theory of how you’ll create value for the customer. Rapidly releasing an initial set of features is the concrete formulation of this theory. You also establish a first baseline to measure progress against. Development is heavily informed by qualitative insights, and ideally,?customer engagement is frequent and collaborative. The still huge gaps in value creation and delivery quickly become evident. So you rapidly learn, adapt, and expand. I’d argue this can be considered a discovery process in itself. As the product stabilizes, the nature of discovery will inevitably shift to accommodate more specific, complex, and strategic challenges. At the end of the day, discovery is not a check-box activity, but a behavior that aims to effectively leverage limited resources for creating value.

This is correct. I’ve been a PM at startups from series B to big tech. I’ve told many PMs who want to go to early stage (pre-series C) to 1. figure out if the startup(aka founder) is at a stage where PMs, in an SV traditional sense, can add value, and 2. whether this type of PM-experience is what they want to deal with. The PM craft required for big tech vs hypergrowth (C,D,etc.) vs drunken-walk (seed, A, B) is very different.

Thanks Matthew for sharing and nice to e-meet you. I personally think that early stage startup founders should take this post with the enough responsibility and see all points of view, because of the huge impact and influence they have on the life of their employees. I think there are a couple of points missing that helps to get the most value out of what you shared: - It’s true that at the beginning, the early stage startup could feel more like a feature factory than anything else, because of some first ideas and steps that the founders want to bring to life. But that’s because of their experience and personal discoveries, and sooner or later the question of the big next step will arise, and that will be easier to answer if done the proper additional discovery previously. - Even when this initial approach is a feature factory in terms of the first product decisions made, that doesn’t means that you can’t start from the very beginning doing continuous discovery (a very basic version of if, due to resources obviously). To be able to prioritize better on your next big decisions, the more understanding of your customers you have will be useful. (A couple of points more on the next comment because of character limit)

I think there's additional nuance here. B2B vs B2C B2C definitely just need to get something out the door to iterate on, so more feature factory like. You need a full product day 1, so big batch. B2B your first client will probably be more like a project where you'll build things that are likely to be for that client only, and come back and productize later, but you can afford the time to do more product work on core product features. The client is likely a bigger company and is nervous about a small company. You still need small batches Infrastructural vs core differentiators The infrastructural bit is where you need to play catch up, and really do feature factory. For core differentiators, you *cannot* be feature factory, but nor is it like 'mature product processes'. It's needs to be highly experimental and iterative, think Skunkworks. You're correct that it's not data informed. It's experts intuition and quick tests with customers. These are still small batch

I don't think delivering in larger batches makes sense for an early-stage startup. You need to be able to quickly test your hypotheses and pivot as soon as you observe that they don't make sense. By delivering in large batches, you have a much higher cost of failed hypotheses. And with early-stage startups there will be a lot of such failures.

I get that you’re using “Feature Factory” to generate engagement - it worked - but if early stage startups have to move quickly and ship often, should we still subscribe to the usage of timeline based roadmaps? Or base our roadmaps on time horizons? We’re trying to prioritize, shift priorities, and move quickly. Timeline roadmaps have become incredibly discouraging and time consuming to maintain in a fast-paced environment. Would love to hear some thoughts from Matthew Zammit and anyone else in the comments section on how early stage startups “should” do roadmaps.

I don’t think this is *wrong*, but a feature factory without the customer discovery leaves you finding some successes that you can’t repeat. Because you have no idea why a feature or function was successful, and how to deliver that value again. It’s not an either or at all. Pre- PMF, we have to (1) deeply understand how to build a product that solves a real problem, (2) ship a bunch fast and track the crap out of everything, and (3) dig into why customers use/don’t use the features we put out. None of those can be skipped.

Slightly disagree on some specifics, massively agree on the general gist. As for the specifics: building is still damn expensive and slow when you have much cheaper and faster options to prototype ideas and get some signals to improve your decisions. Even more so pre PMF. Its just that “signal” is always _qualitative_ at this stage (i. e. your sample size is very small which is perfectly fine, see Hubbard's seminal “How to Measure Anything”) Point in any case: pre PMF is very different from post PMF (and most advice out there is for post PMF, including otherwise great Reforge courses & co.) => Optimise for time-to-insight, go for informed conviction and measure only what you need to reduce uncertainty by one degree (see again Hubbard who should have much more readers in product and general management;?“measure everything” is total nonsense in every context), it's fine to buy learning speed with tech debt, etc.