I’ve always been a big believer in the expedient, “get-it-done” solution; whether it’s a minimum-viable product, a quick, functioning prototype, or a “beta” version of your product or service that provides real experience with real users. You learn a lot when you have something tangible and functioning, and you can buy time as well; time to refine your direction, tune up the feature list and complete the full build-out. In many cases, in my experience, a process offered as a “service” can be converted to a scalable and profitable “product” over time, as elements of the service are turned into software. This approach can result in a product that is well tuned to the needs of the target user, especially if it’s developed with real users, development partners and the like, but there is a risk in this approach.
Filling a gap in your web app with human operators runs a real risk of drifting away from the product design. People are exceptionally versatile, and if a Dev/Ops team is stepping in to complete a portion of the process, they can do things that your automated software systems cannot hope to match. If customer requests are pulling them into “custom” territory, you will want to consider whether the product definition needs to be adjusted. Getting real feedback from early customers, or development partners, is an important benefit of this approach. However, these custom services might not be scalable or profitable in the final product.
In my experience with this product development approach, we’ve learned some very important lessons from our initial users, but we also had eager support team members over-deliver in ways we could not replicate in the final product. In one case, the initial customer/partner was very excited with the first experiences and expected to expand the app across their organization, but we had to re-adjust expectations. In the end, we met in the middle, spending more than planned developing advanced functionality that only partially replicated what the customer had learned to expect. Pay more and deliver less... Ouch!
I believe the application architect needs to take responsibility for assuring that the full product design, planned to be scalable and profitable, is being respected in any short-term elements employed in the tests or development phase. That's not always an easy thing to do, but it's important. The architect should also be attentive to what the initial users are requesting of the Dev/Ops team. As mentioned earlier, the flaws in your initial product design will become apparent as soon as real users get deep into the app, so here is your chance to adjust and get it right.

Comentários