Articles

Stratégies LLM pour les gestionnaires de produits

Stratégies LLM pour les gestionnaires de produits

,

Les gestionnaires de produits doivent adopter des stratégies de gestion de la vie des produits (LLM) pour garantir le succès à long terme de leurs produits.

Embarquer dans l’excitante aventure de faire passer un produit de l’idée à sa mise sur le marché nécessite une planification et un storytelling minutieux. Les responsables produits jouent un rôle crucial dans la définition et la gestion du succès d’un produit. De l’idée à sa mise sur le marché, les responsables produits doivent naviguer à travers divers défis et prendre des décisions stratégiques. En tant que responsable produit, créer des récits et des stratégies convaincants est essentiel au succès. Alors que le LLM bouleverse le marché, les PM peuvent utiliser les LLM pour construire des stratégies efficaces à chaque étape du cycle de vie du produit afin d’améliorer leur productivité.

L’architecture d’un produit est un voyage passionnant qui commence par une idée et se termine par son lancement sur le marché. Les chefs de produit jouent un rôle crucial dans la définition et la réussite d’un produit. De la conception de l’idée à son lancement sur le marché, les chefs de produit doivent relever de nombreux défis et prendre des décisions stratégiques. En tant que chef de produit, il est essentiel de créer des récits et des stratégies convaincants pour réussir. Avec l’arrivée des modèles d’apprentissage automatique, les chefs de produit peuvent utiliser ces outils pour construire des stratégies efficaces à chaque étape du cycle de vie du produit et améliorer leur productivité.

Cet article vise à identifier le cycle de vie d’une idée à son lancement sur le marché et à montrer comment nous pouvons utiliser l’ingénierie prompte pour interroger un modèle d’apprentissage automatique et augmenter la productivité en tant que chef de produit.

L’architecture d’un produit est un processus complexe qui nécessite une planification et une gestion minutieuses. Les chefs de produit doivent être en mesure de comprendre les différentes phases du cycle de vie du produit et de prendre des décisions stratégiques à chaque étape. La première étape consiste à développer une idée et à la transformer en un produit viable. Une fois que le produit a été conçu, les chefs de produit doivent le tester et le lancer sur le marché. La dernière étape consiste à surveiller les performances du produit et à apporter des modifications si nécessaire.

Les modèles d’apprentissage automatique peuvent être utilisés pour améliorer le processus d’architecture du produit. Les chefs de produit peuvent utiliser ces modèles pour analyser les données du marché et prendre des décisions plus éclairées. Les modèles peuvent également être utilisés pour tester le produit avant son lancement et identifier les points forts et les points faibles. Enfin, les modèles peuvent être utilisés pour surveiller les performances du produit et apporter des modifications si nécessaire.

En conclusion, l’architecture d’un produit est un processus complexe qui nécessite une planification et une gestion minutieuses. Les chefs de produit peuvent utiliser les modèles d’apprentissage automatique pour améliorer le processus d’architecture du produit et augmenter leur productivité. Les modèles peuvent être utilisés pour analyser les données du marché, tester le produit avant son lancement, surveiller les performances du produit et apporter des modifications si nécessaire.

Source de l’article sur DZONE

/par
Trois étapes du processus de développement de produit

Trois étapes du processus de développement de produit

,

Le développement d’un produit peut être divisé en trois étapes principales : conception, production et commercialisation. Découvrez comment chaque étape contribue à la réussite du produit !

Rôle du gestionnaire de produit

Product Development Process

The product development process is a continuous cycle of research, design, development, testing, and launch. The product manager is responsible for ensuring that the product is built according to the product vision and that it meets the needs of the customer. The product manager will also need to ensure that the product is tested thoroughly before launch.

Frameworks

Frameworks are useful for product managers to remember the overall product development process. Some popular frameworks include Lean, Agile, and Scrum. Each of these frameworks has its own set of principles and practices that can be used to guide the product development process. The product manager should be familiar with the different frameworks and be able to apply them to their product development process.

Le rôle du Product Manager

Les Product Managers ne sont pas des managers de quiconque, à l’exception des stagiaires qui aspirent à devenir eux-mêmes des Product Managers. Le PM agit comme un noeud central dans le processus de développement du produit et est en fin de compte responsable du succès du produit. Le rôle réunit tous les points de vue et est conçu sans rapports directs afin que l’équipe d’ingénierie/design puisse établir une relation de communication ouverte pour exprimer leurs idées et leurs préoccupations.

Processus de développement du produit

Le processus de développement du produit est un cycle continu de recherche, de conception, de développement, de test et de lancement. Le Product Manager est responsable de s’assurer que le produit est construit conformément à la vision du produit et qu’il répond aux besoins du client. Le Product Manager devra également s’assurer que le produit est bien testé avant son lancement.

Cadres

Les cadres sont utiles pour que les Product Managers se souviennent du processus de développement du produit dans son ensemble. Certains cadres populaires incluent Lean, Agile et Scrum. Chacun de ces cadres a ses propres principes et pratiques qui peuvent être utilisés pour guider le processus de développement du produit. Le Product Manager devrait être familier avec les différents cadres et être en mesure de les appliquer à son processus de développement du produit.

Le test est une étape importante du processus de développement du produit. Il est essentiel que le produit soit testé avant son lancement afin d’identifier et de corriger les bogues et les problèmes techniques avant qu’ils ne deviennent des problèmes pour les clients. Les tests peuvent être effectués manuellement ou automatiquement, en fonction des exigences du produit et des ressources disponibles. Les tests manuels peuvent être effectués par des humains ou par des robots, tandis que les tests automatisés peuvent être effectués à l’aide d’outils logiciels spécialisés. Les tests peuvent également être effectués à l’aide d’outils d’analyse des performances pour vérifier la qualité et la stabilité du produit.

Le rôle du Product Manager est crucial pour le succès d’un produit. Il est responsable de veiller à ce que le produit soit construit selon la vision du produit et réponde aux besoins des clients. Il doit également s’assurer que le produit est bien testé avant son lancement. Les cadres tels que Lean, Agile et Scrum peuvent être utilisés pour guider le processus de développement du produit. Enfin, les tests

Source de l’article sur DZONE

/par

The Serverless Database You Really Want

,

The dreaded part of every site reliability engineer’s (SRE) job eventually: capacity planning. You know, the dance between all the stakeholders when deploying your applications. Did engineering really simulate the right load and do we understand how the application scales? Did product managers accurately estimate the amount of usage? Did we make architectural decisions that will keep us from meeting our SLA goals? And then the question that everyone will have to answer eventually: how much is this going to cost? This forces SREs to assume the roles of engineer, accountant, and fortune teller.

The large cloud providers understood this a long time ago and so the term “cloud economics” was coined. Essentially this means: rent everything and only pay for what you need. I would say this message worked because we all love some cloud. It’s not a fad either. SREs can eliminate a lot of the downside when the initial infrastructure capacity discussion was maybe a little off. Being wrong is no longer devastating. Just add more of what you need and in the best cases, the services scale themselves — giving everyone a nice night’s sleep. All this without provisioning a server, which gave rise to the term “serverless.”

Source de l’article sur DZONE

/par

Case Study: Redesigning Todoist for Android

,

Todoist is a to-do list app that 25 million people rely on every day to keep their lives organized. As part of the Doist design team’s goals for 2021, we aimed to redesign the Todoist Android app to take advantage of the latest Google Material Design guidelines.

In this post, we cover the design decisions and processes behind redesigning the Todoist Android app for Material Design. We explore the Design and Android team’s collaboration practices that brought the app update to life, which resulted in winning the Material Design Award 2021 in the large screen category. Let’s get started!

Opportunity

When we started the project, our design implementation on Android was ready for a major overhaul. The last milestone redesign on Android was initiated after the release of the first Material Design guidelines in 2016. Since then the team successfully worked on continuous improvements to the Android app, but we saw the opportunity to improve Todoist on Android on a more holistic level.

We set out to clean up instances of older UI components, colors, and text styles and update them with the latest Material Design components. We observed that some interactions and navigational patterns had become inconsistent with what users were expecting on newer Android devices and were eager to modernize this experience. With new hardware and software changes in mind, we set out to make the experience on larger phones and tablets even better, so Todoist could take full advantage of the latest generation of devices. Material 2 and 3 provided an incredible new framework to rethink the current app experience. With this in mind, we set out to challenge what a modern Android app should look like and innovate on top of the default user experience.

Solution

The team set itself the goal of redesigning our Todoist Android app and aspiring to make it the best-designed productivity app on Android. The project was ambitious and scheduled to take several months to complete. We set ourselves the following targets while working on the project:

  • Review the current implementation and older design specs.
  • Study the latest Material Design Guidelines and assess what is relevant for our project.
  • Research great Material Design apps and case studies and learn from their execution.
  • Define the new Todoist Android app design language and document the changes.
  • Design and development work together to assess the proposed solution and implementation.
  • Test an early version of the new app internally to gather feedback and make adjustments.
  • Invite beta testers to the new app to gather feedback and make adjustments.
  • Refine the app and address core issues before launching to the public.

Review

The project was kicked off by reviewing the current Todoist Android app implementation, noting down what areas needed to be fixed and what was up to date. While reviewing, we took screenshots of the app implementation for reference. This way we could easily see the current state of the app and compare it to the new design proposals that would be created. Once the review process was finalized, we had a comprehensive overview of the current state of the app and the layout, component, and styling changes we wanted to make.

Study

We continued the project by studying the latest Material Design Guidelines, assessing the components and practices that were most relevant to Todoist.

When the project kicked off in February 2021, Material 2 was the most recent version of their design system. Since Material 2 had already been released for quite some time, we anticipated that design changes to Material would be announced soon at the Google I/O event in May 2021. Rather than wait, because we expected the changes to be iterative, we pushed ahead with our work.

We identified 25 components and UI patterns that we wanted to change across the app. The changes included buttons, forms, menus, sheets, navigation drawer, app bar, system bars, text and color styles, and more. We started by creating a table view in a Dropbox Paper document with the component changes and references links to Google’s Material Design Guidelines.

This components list was a starting point for discussion to plan the scope and complexity of the changes. Close async discussions between the design and development team in Twist and Dropbox Paper comments helped us make decisions about scope and complexity early on and set a solid foundation for the project.

Research

In the initial Material Design study, we also researched inspiring Material Design apps, Material studies, Play Store apps, and Google Workspace apps to learn from their execution.

We started out by studying the Material Design Award Winners 2020 and tested out the products that were showcased. The showcased winners struck a good balance between implementing the Material Design Guidelines while maintaining their own product’s brand within the system. This balance between Google’s guidelines and the Todoist brand was also key for us to get right and so we strived to find this mix across the work we created and implemented in the project.

Along with the MDA winners, we researched the Material Studies that Google produced to showcase what apps could look like with branding and Material Design guidelines applied. It was a great reference to see how far components could be customized while maintaining the core platform principles. The Reply case study in particular offered valuable insight to us as its content type and layout came closest to Todoist. It showcased how components like the app bar, navigation drawer, and large screen layouts worked while being customized.

We continued our research by searching the Google Play store for inspiring app examples. Google Tasks, Press, Periodic Table, and Kayak stood out to us as the level of polish and quality of the apps were on par with the experience we were aspiring to create.

Sometime later in the project when Material You was released (more on that later), we stumbled upon the Google Workspace apps blog post which previewed Material 3 changes that Google was introducing to their own products. It offered a great glimpse at what was to come before the Material 3 Design Guidelines were officially released. This post sparked new internal discussions and further design explorations that we considered for future Todoist Android updates.

Design Spec

As we started to define the new Todoist Android app design language and document the changes, we opted to create a design framework, focusing on creating components rather than designing every screen in the app. This allowed us to consistently apply the design system in the app. We did so by using the previously defined component list that we created during the review and study process.

Core screens from different areas of the app were chosen to demonstrate how the components could be applied. We chose to mock up the Todoist project view, navigation drawer menu, project view edit screen, settings, and project detail view, among others. These screens gave us a good overview of how buttons, forms, drawers, lists, and other components would work together and in different states; selected, pressed, disabled, etc.

During the project, we were transitioning our Doist design system to Figma and started creating our first components in the new Doist Product Android Library. We started by using some components from the Material Design UI kit – Components library from the official Google Figma resource file and added them to our Doist design system. We then continued to build up the Product Android Library file with our Todoist-specific components such as task list & board views, detail views, sheets, colors, typography, etc.

We continued by documenting color and typography changes that were based on the Material Design guidelines. The design team opted to implement a new Design Token framework that would share the same values between our design system and the development implementation. The development team would output the values they had in the current implementation and the design team would analyze which values were needed and which could be merged, changed, or deleted. This informed the new Design Token color and typography system which we then documented and discussed with the team to implement. Later in the project, we were happy to see a similar token system introduced by Material 3 in the latest guidelines which validated our thinking and principles behind the new design system.

The design documentation expanded to hold other edge-case mockups that could sit alongside the design system. We documented different responsive screen experiences between phones and tablets against the previous implementation. Additional sections were created to document the motion that should be used for certain components and screens by referencing existing Material Design guidelines examples or prototyping custom motion in Principle and After Effects. The design spec also touched on haptic feedback that should appear on touch targets, how dark mode should work across the new components, documenting Todoist themes within the new design language, and more.

Design Implementation

At Doist, the benefit of the squad is that cross-team collaboration is built into the make-up of the team. Designers, developers, support, and product managers work together in a squad to deliver the project. This close collaboration from the start is key to bridging the gap between scope, estimations, design, development, and delivery. The squad discussed their findings on a daily basis and came up with the best plan of action together.

Designers started by creating components in Figma and shared them with developers in Dropbox Paper. We used screenshots to document the current implementation next to the new designs and linked to the default Google Material Design components. This allowed the team to compare all references in one place. Developers shared their feedback, adjustments would be brainstormed together as the designs were iterated.

Designers on the project would share their work in progress on a weekly basis with the rest of the design team in a design review Twist thread. Here details about the designs were discussed, alternatives mocked up and bigger picture plans made. Design reviews brought up topics like FAB (Floating Action Button) placement, theme options, accent color usage on components, consistency with other platforms, navigation options, and shadow elevation. After thorough discussions and alternative mockups were presented, the design team aimed to find the right balance between Material Design and Todoist brand guidelines. The development team, also part of the design reviews, gave their feedback on the solution and raised technical complexities early on.

Eventually, the design was stabilized and consistencies updated across components and mockups. The design spec was kept up to date so the development team could always review the latest designs in Figma.

Testing

As soon as the development process started, the Android team provided early screenshots and videos in Twist threads while they were implementing the design spec. This practice allowed us to review the app implementation early and often. Designers could review the development work and share feedback in Twist, which resulted in getting the implementation to a high quality. Alongside Twist discussions, the team set up a Todoist project to track ongoing issues and fix bugs. Designers logged new issues, developers would solve them and share the new implementation for designers to review.

When the team had the first stable version of the Android app, we shared it internally at Doist to get more insight and feedback. Other Doisters could access the redesign via a feature flag that could be turned on in the app settings and test the new version for however long they wanted. The feature flag system allowed people to give us early feedback on the design decisions we made and report bugs. Feedback was submitted by the wider team through a dedicated Twist thread and designers and developers could discuss how best to address the feedback during the active project implementation.

After we refined the app implementation further and addressed early feedback we opened up the app update to our beta users. Here users had access to the new Android redesign and were able to give us feedback. Our support team gathered feedback and shared it with us in a dedicated Twist thread. The squad aimed to analyze every comment and looked for patterns where we could make tweaks and improvements to the user experience.

As part of these tweaks, we made changes to how the bottom bar and navigation drawer worked. Some users reported frustrations with the way the new bottom navigation and menu drawer worked. In its first implementation, the drawer was half raised when opened and had to be swiped up to be raised again to see the full content list. This was an issue for some users as it was slower to get to the content below the list. So we decided to fully raise the drawer by default when opening. We also made it easier to open the navigation drawer by sliding up from the bottom app bar. This was a small shortcut but it enabled users to get to their content faster.

Material You

While we were in the testing phase and about to wrap up the project, Google unveiled Material You, and sometime later the Material 3 Guidelines were published. With the newly announced resources, we went back to study the latest guidelines and references we could find to see where the Todoist Android app redesign fits in and which adjustments we might need to make now or in the future.

Dynamic Color was a big new feature that was announced as part of the Material You update. As Todoist supports many different themes the Material You Dynamic Color feature seemed like a good fit for our product. We decided to prioritize this feature and implement Dynamic Color light and dark themes as part of our Todoist theme settings options.

To implement Dynamic Color, the development team started off by creating a demo prototype that utilized the Dynamic Color system and showcased how we could select from a range of color choices that the system defined based on the wallpaper choice. From there, we tried to incorporate system behavior in our design mockups. We designed a range of different color mockups and components to see which ones could fit with which components. We then came up with a color system that worked for the Todoist app and the new themes. These new Dynamic Color themes would sit alongside our current theme options in the Todoist app settings. From here users could choose between Dynamic Color Light and Dark themes.

Along with Dynamic Color, the team also created a customizable bottom app bar, allowing users to set up the app in a way that’s most convenient to their workflow. The location of the Dynamic Add Button can be changed to the center, left, or right corner of the screen. The order of the Menu, Search, and Notification buttons can be rearranged to best fit the ergonomics of the user’s dominant (left or right) hand and optimize their navigation patterns.

Launch

As critical beta feedback was addressed and stability tweaks were made, the squad felt ready to release the new Todoist Android app to the public. The team logged the issues that could not immediately be addressed for future reviews and updates.

The design and marketing team readied the launch by creating What’s New banner artwork and copy that are displayed within the app when launching the update. The Doist marketing team also created release notes and shared the app update announcements on our social channels. The brand and product design team worked together to create custom image assets and copy that summarised the project work in a simple and beautiful way.

What’s Next: Material 3

After a successful launch of the redesigned Todoist for Android app, Google contacted Doist to announce that Todoist was selected as the Material Design Award 2021 winner in the Large Screen category. The team was excited to be recognized for their hard work and it felt like we achieved the goal we had set out to accomplish.

Internally, designers and developers continued to study and discuss the Material 3 updates. The design team started exploring mockups and design changes inspired by Material 3 and Google’s Workspace app updates. Some of our current Todoist explorations include changing the FAB styling, updating the app bar, further removing elevation shadows, and more. Here is a preview of what a future Todoist update could look like.

We hope these insights into Doist’s design process and collaboration practices have sparked your interest. Thank you for reading and stay tuned for future design updates!

Takeaways

  • Study the Material guidelines, Material Design winners, Material studies, and Google Workspace apps to make informed design decisions when designing your next product or app update.
  • Evaluate which Material Design components and practices are right for you and implement them into your product.
  • Carefully balance the Material Design guidelines with your brand guidelines to create a unique and consistent experience between your product and the platform it lives on.
  • Collaborate with your Android developers early and often to ship app updates efficiently and increase the design implementation quality.
  • Use design components and build a design system along with practical mockups to create an efficient design spec.
  • Consider how the latest Android features fit into your product and which have the most impact on your users before deciding to implement them.
  • Test and review builds with your internal team and external beta users to get valuable feedback and make adjustments before releasing them to the public.
  • Create announcement artwork to showcase your latest app or feature update along with a clear description to share in-app and on social media.

Source

The post Case Study: Redesigning Todoist for Android first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

/par

7 Approaches To Testing

,

Originally published on August 17, 2020

This article will be interesting for IT directors, product managers, project managers, and anyone who wants to understand the processes of project quality assurance better.

Source de l’article sur DZONE

/par

No-Code:  »It’s a Trap! »

,
Gartner predicts that by 2023, over 50% of medium to large enterprises will have adopted a Low-code/No-code application as part of their platform development.
The proliferation of Low-code/No-code tooling can be partially attributed to the COVID-19 pandemic, which has put pressure on businesses around the world to rapidly implement digital solutions. However, adoption of these tools — while indeed accelerated by the pandemic — would have occurred either way.
Even before the pandemic, the largest, richest companies had already formed an oligopsony around the best tech talent and most advanced development tools. Low-Code/No-code, therefore, is an attractive solution for small and mid-sized organizations to level the playing field, and it does so by giving these smaller players the power to do more with their existing resources.
While these benefits are often realized in the short term, the long-term effect of these tools is often shockingly different. The promise of faster and cheaper delivery is the catch — or lure — inside this organizational mousetrap, whereas backlogs, vendor contracts, technical debts, and constant updates are the hammer.
So, what exactly is the No-Code trap, and how can we avoid it?

What is a No-Code Tool?

First, let’s make sure we clear up any confusion regarding naming. So far I have referred Low-Code and No-Code as if they were one term. It’s certainly easy to confuse them — even large analyst firms seem to have a hard time differentiating between the two — and in the broader context of this article, both can lead to the same set of development pitfalls.
Under the magnifying glass, however, there are lots of small details and capabilities that differentiate Low-code and No-code solutions. Most of them aren’t apparent at the UI level, leading to much of the confusion between where the two come from.
In this section, I will spend a little bit of time exploring the important differences between those two, but only to show that when it comes to the central premise of this article they are virtually equivalent.

Low-Code vs. No-Code Tools

The goal behind Low-Code is to minimize the amount of coding necessary for complex tasks through a visual interface (such as Drag ‘N’ Drop) that integrates existing blocks of code into a workflow.
Skilled professionals have the potential to work smarter and faster with Low-Code tools because repetitive coding or duplicating work is streamlined. Through this, they can spend less time on the 80% of work that builds the foundation and focuses more on optimizing the 20% that makes it different. It, therefore, takes on the role of an entry-level employee doing the grunt work for more senior developers/engineers.
No-Code has a very similar look and feel to Low-Code, but is different in one very important dimension. Where Low-Code is meant to optimize the productivity of developers or engineers that already know how to code (even if just a little), No-Code is built for business and product managers that may not know any actual programming languages. It is meant to equip non-technical workers with the tools they need to create applications without formal development training.
No-Code applications need to be self-contained and everything the No-Code vendor thinks the user may need is already built into the tool.
As a result, No-Code applications create a lot of restrictions for the long-term in exchange for quick results in the short-term. This is a great example of a ‘deliberate-prudent’ scenario in the context of the Technical Debt Quadrant, but more on this later.

Advantages of No-Code Solutions

The appeal of both Low-Code and No-Code is pretty obvious. By removing code organizations can remove those that write it — developers — because they are expensive, in short supply, and fundamentally don’t produce things quickly.
The benefits of these two forms of applications in their best forms can be pretty substantial:
  • Resources: Human Capital is becoming increasingly scarce — and therefore expensive. This can stop a lot of ambitious projects dead in their tracks. Low-Code and No-Code tools minimize the amount of specialized technical skills needed to get an application of the ground, which means things can get done more quickly and at a lower cost.
  • Low Risk/High ROI: Security processes, data integrations, and cross-platform support are all built into Low-Code and No-Code tools, meaning less risk and more time to focus on your business goals.
  • Moving to Production: Similarly, for both types of tools a single click is all it takes to send or deploy a model or application you built to production.
Looking at these advantages, it is no wonder that both Low-Code and No-Code have been taking industries by storm recently. While being distinctly different in terms of users, they serve the same goal — that is to say, faster, safer and cheaper deployment. Given these similarities, both terms will be grouped together under the ‘No-Code’ term for the rest of this article unless otherwise specified.

List of No-Code Data Tools

So far, we have covered the applications of No-Code in a very general way, but for the rest of this article, I would like to focus on data modeling. No-Code tools are prevalent in software development, but have also, in particular, started to take hold in this space, and some applications even claim to be an alternative to SQL and other querying languages (crazy, right?!). My reasons for focusing on this are two-fold: 
Firstly, there is a lot of existing analysis around this problem for software development and very little for data modeling. Secondly, this is also the area in which I have the most expertise.
Now let’s take a look at some of the vendors that provide No-Code solutions in this space. These in no way constitute a complete list and are, for the most part, not exclusively built for data modeling. 

1. No-Code Data Modeling in Power BI

Power BI was created by Microsoft and aims to provide interactive visualizations and business intelligence capabilities to all types of business users. Their simple interface is meant to allow end-users to create their own reports and dashboards through a number of features, including data mapping, transformation, and visualization through dashboards. Power BI does support some R coding capabilities for visualization, but when it comes to data modeling, it is a true No-Code tool.

2. Alteryx as a Low-Code Alternative

Alteryx is meant to make advanced analytics accessible to any data worker. To achieve this, it offers several data analytics solutions. Alteryx specializes in self-service analytics with an intuitive UI. Their offerings can be used as Extract, Transform, Load (ETL) Tools within their own framework. Alteryx allows data workers to organize their data pipelines through their custom features and SQL code blocks. As such, they are easily identified as a Low-Code solution.

3. Is Tableau a No-Code Data Modeling Solution?

Tableau is a visual analytics platform and a direct competitor to Power BI. They were recently acquired by Salesforce which is now hoping to ‘transform the way we use data to solve problems—empowering people and organizations to make the most of their data.’ It is also a pretty obvious No-Code platform that is supposed to appeal to all types of end-users. As of now, it offers fewer tools for data modeling than Power BI, but that is likely to change in the future.

4. Looker is a No-Code Alternative to SQL

Looker is a business intelligence software and big data analytics platform that promises to help you explore, analyze, and share real-time business analytics easily. Very much in line with Tableau and Power BI, it aims to make non-technical end-users proficient in a variety of data tasks such as transformation, modeling, and visualization.

You might be wondering why I am including so many BI/Visualization platforms when talking about potential alternatives to SQL. After all, these tools are only set up to address an organization’s reporting needs, which constitute only one of the use cases for data queries and SQL. This is certainly a valid point, so allow me to clarify my reasoning a bit more.

While it is true that reporting is only one of many potential uses for SQL, it is nevertheless an extremely important one. There is a good reason why there are so many No-Code BI tools in the market—to address heightening demand from enterprises around the world — and therefore, it is worth taking a closer look at their almost inevitable shortcomings.

Source de l’article sur DZONE

/par

Best Tips to Manage Your Remote Software Development Teams

,

For a few years now, remote software development has become quite the trend and favorite. Remote software development teams who constitute remote development are usually a team of designers, product engineers, scrum masters, developers, and product managers. All of them work individually over the project cumulatively, resulting in a product’s delivery. 

Generally, in outsourcing, the concerned remote software development company will have dedicated managers overseeing the projects. But post the outbreak of the dreaded pandemic, things are changing. Due to work from home, remote teams operate from different locations. For Business Owners, it is a tedious task to ensure the management of these teams. If you happen to be outsourcing your product development or hiring a remote team to design, develop, and deliver projects, here are a few coolest tips to help you manage them. 

Source de l’article sur DZONE

/par

What Are Good Traits That Make Great API Product Managers

,

As more companies realize the benefits of an API-first mindset and treating their APIs as products, there is a growing need for good API product management practices to make a company’s API strategy a reality. However, API product management is a relatively new field with little established knowledge on what is API product management and what a PM should be doing to ensure their API platform is successful.

Many of the current practices of API product management have carried over from other products and platforms like web and mobile, but API products have their own unique set of challenges due to the way they are marketed and used by customers. While it would be rare for a consumer mobile app to have detailed developer docs and a developer relations team, you’ll find these items common among API product-focused companies. A second unique challenge is that APIs are very developer-centric and many times API PMs are engineers themselves. Yet, this can cause an API or developer program to lose empathy for what their customers actually want if good processes are not in place. Just because you’re an engineer, don’t assume your customers will want the same features and use cases that you want.

Source de l’article sur DZONE

/par

How a Program Manager, Product Manager, and Project Manager Collaborate

,

There are so many different roles in the project development, and it is so easy to get lost in their concepts and responsibilities. 

In our article, we consider three main positions in IT industry: the product manager, the project manager, and the program manager. All these specialists are the key players in project development, so it is important to differentiate their professional hues.

Source de l’article sur DZone (Agile)

/0 Commentaires/par