Digital Product Insights

One of the reasons the role of a Product Manager(PM) comes across as ambiguous is because the role of a Product Manager differs from every company and lifecycle of a product. If you’ve socially introduced yourself as a product manager, you must’ve come across questions regarding your profile in the vein of, “what is it that you do?” You probably stumbled and hesitated over the answer initially and now comfortably throw out some jargon like “customer advocate,” and “cross-functional teams” and receive a thoughtful nod and the occasional blank stare from whoever asked the question.

Django came into the scene right as the first big wave of Rails hype was ramping up, and so it was immediately positioned as Python's answer to Rails and thus grabbing eyeballs almost from the start. Today, one of the most significant advantages of learning Python is the ability it gives you to use Django. What with tech startups being so hot right now, it’s never been easier or more fun to build your own web application. Django just might be your answer. It has been rapidly gaining popularity for its pragmatic design and ease of use.

It feels like everyone today wants to build the next great scalable web application. Amazon Web Services has emerged as one of the leading cloud providers when it comes to deploying and scaling our web applications. If you’re new to AWS, it can seem overwhelming. Today, there are over 40 different AWS services, and many concepts to consider when building your application. However, AWS provides helpful guides, excellent documentation on each of their services, white papers, reference architectures for common apps and more. Now, coming to Rails, the idea of adopting it, wasn't given weight merely because of its technicalities, but rather because it is an ecosystem developed for startups. Thanks to its big-name users like Twitter, Groupon, and Hulu and all the Agilists hyping Rails, has sparked the need for services like Heroku, AWS, New Relic, and Github, allowing Rails to scale.

Even with all the evidence pointing in favor of building your application, don't decide to move forward lightly. With over 1.5 million apps each in Apple’s App and Google Play Store, it’s important to run through the mobile app development process and how your application will fit in with both your marketing goals and your market niche. Mobile App Development Lifecycle is just a representation of the conventional Software Development Lifecycle (SDLC) from the perspective of a mobile device.

Building a profitable product, which excites your users and isn’t a technological minefield at the same time, can prove tricky. It can almost seem impossible for the rest of us who aren’t tech giants. Stories about product failures and startups who closed down, don’t make a fun read on a Sunday morning. We prefer to celebrate success, so we rarely hear about them. Countless failed startups never got the product right, and a rivaling number of large company products were huge flops despite the marketing force behind them. Without a great product or service, you cannot build a great company. This might sound obvious, yet many still believe spending money on great marketing and PR can sell products. This is because the alternative of investing in building great products seems more time consuming and sometimes, a maze.

Your devices and products might look the same as they did before they got connected and smart. Even so, they’re fundamentally different. Now they’re members of a larger community of processes, products, and stakeholders. Ensuring your products are capable of filling these new roles is a serious design challenge. You see, machine-to-machine connectivity, the forerunner of consumer-focused IoT has been around for decades. More often than not, the M2M phase of IoT applications pushed technology to address B2B market requirements. Product design considerations in that phase were not critical to persuading customers to adopt offerings. Enterprise IoT buyers seldom require great design, because most often the buyer is not the product’s end user. However, today when the application of IoT has expanded to a broader range of commercial opportunities, enterprise B2B applications have become B2B2C.

Mobile Backend-as-a-Service or MBaaS was born to allow mobile developers who were short on time and wanted to build solutions by taking advantage of the latest features in a mobile device as well as manage complex service commands. The early leader in this nascent space was Parse. Parse set the groundwork for all MBaaS companies, providing us with cost-effective and easy-to-use tools for MBaaS. Earlier this year the service shut down. But the momentum of Parse opened up a path for other services to compete in the same space. The three emerging leaders in this space are Google’s Firebase, Apple’s CloudKit, and Kinvey.

Firebase started out as a cloud database which grew to include notifications, authentication, and other features. At face value, it looks interesting, allowing mobile devices to load and store data using the Firebase API, eliminating the need for owning any back-end server or hosting. To keep in sync easily, it’s possible for different devices using Firebase to get events on data changes. As its native format, the database uses JSON, a good fit for a web or mobile application. Firebase supports Web, Android, and iOS. This goes to mean it supports native apps plus a website or a web-based admin component. V3, the latest version of Firebase, is now completely hosted on Google Cloud and introduced us to some nice features like the Push notifications for iOS/Android and cloud storage.

Today, most tech jobs come with a flexible schedule. Nobody wants a team of stressed out, overworked and underpaid developers working on their project. No matter how strong the passion for your job is starting out, to sustain this passion, one needs balance and the ability to prioritize. When you start out as a Ruby on Rails developer, you’re faced with some important questions: How much time should you spend billing? Will you have time to take care of normal daily tasks? What does a typical day look like? What about a social life?

Since the 1960s, cloud computing has allowed us to take advantage of its manageability and elasticity. It gave us the power to own a new server. It opened a whole new door to higher level platform services like API gateways, queues, authentication and more. Are we to embrace serverless next? Most think and talk of serverless in the same breath as FaaS (functions-as-a-service) products, understandably so, and since they were disappointed with those, they overlook serverless entirely. Well, they’ve missed out. Seeing as you are here, your view isn’t as narrow.

If you’ve already started shopping for the right vendors or freelancers to work on your MVP, you would have come across the huge disparity in the prices they quote. Often the disparity in the prices they quote is so huge that you begin to wonder whether all those prices are to build the same MVP. Before we get into the right pricing and how to determine whether the quote is correct, you as startup founders and product leaders should go deep. Meaning, break down the requirements and prioritize. This will help you understand whether what you’re looking to build is truly an MVP or a prototype.

There’s no escaping JavaScript when it comes to building a Rails application. Whether we prefer it or not from a small script to a full-blown JavaScript framework websites, have become far more dependent on JavaScript. Back in the day, all you needed was a single stylesheet for a project. Today, Rails projects have an asset pipeline which helps us create different sets of stylesheets or manifests. You run through the stylesheets and tie it all to the javascript architecture. This asset pipeline has made it a lot easier to include JavaScript in Rails applications. The code included in your application is executed on all pages without any extra changes. Nevertheless, you can isolate certain JavaScript code to run only on specific pages by combining CSS class scopes and a jQuery plugin.

Often, people tend to water down the message in the contract to translate to how money exchanges hands, when in reality it will dictate a lot more than this. The contract will drive the behavior of engagement, timelines, and more. No matter the engagement model you choose to go with, ensuring the project meets expectations and stays on track becomes a shared goal for both of you. Even so, make sure you adopt the right contract to pave for a smoother engagement process.

Node.js gave us cutting-edge web applications with two-way, real-time connections where both the client and server could communicate with each other. A stark contrast to the conventional web response paradigm where only the client initiates communication. It’s quite similar to what Ruby On Rails and ASP.NET have to offer. Powered by Google’s extremely fast V8, it leverages JavaScript, the lightweight built-in web server as the primary language and has a plethora of Plugins managed through the Node Package Manager, allowing one to custom-build applications to meet their needs. Most of this sounds like any other good technology, but it comes with certain features which have made it a popular choice among developers to build a broad spectrum of web applications.

Change by its nature, is hard in the beginning, messy in the middle and worthwhile in the end if the transition goes well. Handing over a SaaS development project from one company to another, midway is bound to get messy. The project manager who has to take over your project all of a sudden, probably had a lot on his plate, or maybe was spearheading a critical project he had invested a lot in, but now has been moved to yours. A good project manager understands perhaps his skill sets were more necessary to your project currently than the one he was working on or there were other extenuating circumstances. Whatever the reason, often they aren’t given the right of first refusal. Nevertheless, end of the day, everybody on the project wants the best handoff.